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REMARKS 

With regard to Examiner's paragraph 2, copies of 15 documents which, according 
to our records, were given by Lucent at the meeting are enclosed. According to Lucent 
and 3 GPP records, there was a further document S2-00051 1 from Lucent, which was 
withdrawn. The inventor has left Lucent but according to another Lucent employee 
attendee at the meeting, this further document S2-0005 1 1 was possibly never submitted 
as it is not available on the 3 GPP website or corresponding Lucent internal website. 
According to the 3 GPP organization ETSI, it was just allocated a number and was not 
submitted by the author. As regards the content of this S2-00051 1 document, we know 
its title "Correction of using UDP for protecting corrupted PDUV and that from 3 GPP 
records it is a revision of an earlier document S2-000365, a copy of which is enclosed 
having the same title, a reference S2-000xxx in the top right corner of its first page, and a 
date of 25 th January 2000. 

According to our records approximately 250 other documents were given at the 
meeting by other parties. It is presumed that the Examiner does not wish for copies of 
those documents from other parties, however they are obtainable from the following web 
address if desired: 

http://www.3Rpp.org/ftp/tsg-sa/WG2.Arch/TSGS2-12/+docs/ 
Incidentally, it is believed that the reference to a disclosure at the meeting referred to on 
page 2, lines 6 to 10 of the present application relates to the Lucent document 
(TSGS2#12 52-000368) identified by the Examiner, see e.g. its page 8, lines 15 to 19 
(Scenario II) and page 8 last line which refers to proxies. 

The reference to the applicants co-pending European patent application has been 
completed by insertion into the specification of the European patent application no 
00303898 which is published as European published patent application number EP-A- 
1 154664. This co-pending patent application was filed on the same day, May 9, 2000, as 
the corresponding European patent application no. 00303897.3 from which priority has 
been claimed in the present application. 

With regard to the Examiner's paragraph 3, the title has been amended as to be 
descriptive and to remove reference to "the future". 
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With regard to the Examiner's paragraph 4, Figures 1 and 2 have been labeled as 
prior art. Various clarifications have been made in the application. A new Figure 7 has 
been added showing the flag. It is believed that all claimed features are shown in the 
amended drawings. 

With regard to the Examiner's paragraphs 3, 5 and 6-11, references to "future" 
have been deleted throughout the application. However, the claimed invention can be 
applied to third generation and future generation telecommunications systems. It is being 
described in the context of a third generation wireless telecommunications system, but 
the claims should not be limited thereto. The Applicant understands the objections raised 
in paragraphs 6 to 1 1 to relate to "future generations" but not the "third generation". 
With regard to the terms mobile terminal and remote user, these terms are well known in 
the field of "third generation" wireless radio networks as well as wireless communication 
systems in general. As mentioned above, all references to "future generations" have been 
removed from the application. Accordingly, it is believed that all rejections in 
Examiner's paragraphs 6 to 1 1 have been overcome. 

With regard to the Examiner's paragraphs 12 to 14, the claims have been 
redrafted. Previous claims 1 to 9 are deleted, new claims 10 and 1 1 being provided in 
which care has been taken to ensure proper antecedent basis, appropriate use of the and 
said, etc. Basis for new claim 1 is provided by previous claims 1, 2 and 6 for example. 

With regard to the Examiner's paragraph 15, reference to "future" has been 
removed as mentioned above. 

The Examiner's paragraph 16 has been addressed by the amendments to the 

claims. 

The claims have been amended to provide an independent claim 10 which clearly 
distinguishes over the cited Lucent reference. Claim 10 is distinguished by the following 
features not disclosed nor taught by the cited Lucent reference: responding to receipt of a 
first RSVP message by "setting a flag in Packet Data Protocol (PDP) Context data for the 
call session, the flag indicating the first RSVP message was received", then upon 
receiving back an RSVP reply message "discarding said RSVP reply message as said flag 
has been set in the PDP Context data". Accordingly, the rejection under 35 USC 102 falls 
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away. Furthermore, the Nokia document mentioned in the Examiner's paragraph 26 does 
not apparently disclose or teach the invention according to claim 10. 

Dependent Claim 1 1 depends on a believed-allowable claim 10, yet provides a 
further distinction in that the support node senses the flag in PDP Context data which it 
receives and so undertakes the discarding step. 

In view of the above, applicants respectfully request reconsideration and 
allowance. In the event of any fees inadvertently omitted or any improper payment of 
fees, the Commissioner is hereby authorized to charge or credit Lucent Technologies 
Deposit Account No. 12-2325 to correct the error now or during the pendency of this 
application. 

If the Examiner has any questions or feels that a telephone conversation would be 
helpful, please contact Julio Garceran at (908) 582-7294. 



Docket Administrator (Room 3J-219) 
Lucent Technologies Inc. 
101 Crawfords Corner Road 
Room 3J-219 

Holmdel, New Jersey 07733-3030 



Respectfully submitted, 



Xiaobao X Chen 




Julio^A. Garceran 
Attorney for Applicants 
Reg. No.: 37138 
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Amendments to the Drawings 

Replacement sheets for Figures 1-6 are being submitted along with a new Figure 

7. 
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5.6.1.1 



MS-GGSN 



The user plane consists of a layered protocol structure providing user information transfer, along with associated 
information transfer control procedures (e.g., flow control, error detection, error correction and error recovery). The 
userplane independence of the Network Subsystem (NSS) platform from the underlying radio interface is preserved via 
the Gb interface. The following userplane is used in GPRS: 
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Figure 1 : User Plane for GPRS 

Legend: 

- GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between GPRS Support 
Nodes in the backbone network. All PDP PDUs shall be encapsulated by the GPRS Tunnelling Protocol. GTP is 
specified in 3G TS 29.060 [26]. 

- UDP carries GTP PDUs for protocols that do not need a reliable data link (e.g., IP), UDP provides protection 
error detection against corrupted GTP PDUs. UDP is defined in RFC 768 [39]. 

- IP: This is the backbone network protocol used for routeing user data and control signalling. The backbone 
network may initially be based on the IP version 4 protocol. Ultimately, IP version 6 shall be used. IP version 4 
is defined in RFC 791. 

- Subnetwork Dependent Convergence Protocol (SNDCP): This transmission functionality maps network-level 
characteristics onto the characteristics of the underlying network. SNDCP is specified in GSM 04.65 [16]. 

- Logical Link Control (LLC): This layer provides a highly reliable ciphered logical link. LLC shall be 
independent of the underlying radio interface protocols in order to allow introduction of alternative GPRS radio 
solutions with minimum changes to the NSS. LLC is specified in GSM 04.64. 

- Relay: In the BSS, this function relays LLC PDUs between the Urn and Gb interfaces. In the SGSN, this 
function relays PDP PDUs between the Gb and Gn interfaces. 

- Base Station System GPRS Protocol (BSSGP): This layer conveys routeing- and QoS-related information 
between BSS and SGSN. BSSGP does not perform error correction. BSSGP is specified in GSM 08.18 [21]. 

- Network Service (NS): This layer transports BSSGP PDUs. NS is based on the Frame Relay connection between 
BSS and SGSN, and may be multi-hop and traverse a network of Frame Relay switching nodes. NS is specified 
in GSM 08. 16 [20]. 

- RLC/MAC: This layer contains two functions: The Radio Link Control function provides a radio-solution- 
dependent reliable link. The Medium Access Control function controls the access signalling (request and grant) 
procedures for the radio channel, and the mapping of LLC frames onto the GSM physical channel. RLC/MAC is 
defined in GSM 04.60 [14], 

- GSM RF: As defined in GSM 05 series. 
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Abstract : This paper discusses architectural requirements and architectural principles for Release 2000. A companion 
paper discusses the architecture model. 



1 Introduction 

At the SA2#1 1 meeting it was agreed that architectural principles should be settled before doing further work on the 
R'OO architecture. The paper from Alcatel served to initiate discussions on this topic. This paper progresses work on this 
topic by discussing the principles in relation to the requirements. 

References used in developing this paper are: 

[1] Input Document S2-000153 from Alcatel to the SA#1 1 meeting 

[2] TR 23.821 V0.1.0 (2000-01) ; output of SA#1 1 meeting, "Architecture Principles for Release 2000" 
[3] TR 23.922 Vl.0.0 (1999-10), die feasibility study on "Architecture for an All-IP network" 
[4] TR 22.976 V0.5.0 (2000-01) "Study on PS domain services and capabilities" 



2 Discussions 

It is important that the architectural principles relate directly to the architectural requirements. Therefore it is suggested 
that first we clarify what are the requirements, then discuss and agree on the architecture principles. It is also suggested 
that we define the TR 23.821 terminology as we go along. Some definitions are proposed here, sSee the companion 
paper for a list of other proposed definitions. 

2.1 Some definitions 

Architectural requirements: These are requirements that should be supported by the network architecture. The y 
include user sendees, operator needs, and some other industry needs such as network evolution and regulatory needs . 

Architectural principles: These are the high level decisions that are used in developing the detailed architecture of a 
specific network. They include choice of network topology to handle user traffic and signalling traffic, identification of 
ma jor functional subsystems and interfaces, modularity of functions within each subsystem, functional layer s 
(sometimes referred to as domains) which represent peer-to-peer functions across subsystems . 

Architecture model: This is the gen e ral model of a telecommunication network to represent the fundamental princ iple s 
that apply to all networks . Such a model is then customised to chow die principles being adopted specifi call v fo r 
R-Wf (duplication with paper 2) 



3GPP 



2.2 The architectural requirements 



TR 23.922 is currently a convenient source of information on all architectural requirements. Full details of user services 
are currently being developed in TR 22.976. Detailing of other architectural requirements is not being done in any 
specific place. Hie Alcatel paper includes a few architectural requirements. To help understand the architectural 
requirements within TR 23.82 1 it is worthwhile to capture a summary of the architectural requirements. 

Although the focus here is generally on the requirements that are new for R'OO, the R'99 requirements should also be 
considered when finalising the architectural principles. 

2.2.1 User services 

These are the services and service quality as perceived by the end-users. End-users include corporations. Refer to TR 
22.976 for the user services. 

2.2.2 Operator needs 

These are the needs for network planning, deployment/provisioning and operation. Such needs are generally transparent 
to end-users. 

Deliver all 3G services using a common network that makes use of packet technology and is evolved from current 
3G architectures (R'99, IMT-2000). The traffic should be supported in the most efficient and economical way. 

• Support multiple means of access, namely 3G radio access technologies (GERAN, UTRAN, EDGE/GPRS), 
conventional wireline, coax/fiber cable, LANs. 

• For radio access, allow efficient use of radio resources and multiplexing of multiple traffic streams on the same 
radio link. 

• Signalling traffic and user traffic should be routed for optimum use of resources and performance. 

It shall be possible for numbering and addressing, and routing to be based on a single identifier. Both dynamic and 
dedicated IP addresses shall be supported. 

• Charging: traffic log etc. consider any additional requirements that may be needed for 3G services. 

2.2.3 Other industry needs 

These are die broader needs of industry, including those of equipment vendors and regulators. 

Allow independent evolution of circuit switched and packet switched infrastructures so that individual networks 
may have a choice of evolution paths and deployment. 

Support service offerings being independent from transport technology, so they can evolve independently 

• Maintain independent evolution of radio dependent parts in the RAN and radio independent parts in the CN. 

• Allow a smooth evolution from hybrid networks to future converged networks in future releases. 

2.3 The architecture principles for R'OO 

The following architecture principles are proposed for R'OO. They need to be considered together with architecture 
principles from R'99 when developing the R'OO architecture. 

1) Need both circuit-mode and packet-mode domains 

Considering the traffic mix resulting from the set of 3G services and the need for flexible evolution paths, it is 
necessary to have separate circuit switched domain (based on current wireless networks) and packet switched 
domain (based on the current IP network). 



Each domain will handle its own signalling traffic, switching and routing. 

2) Keep network functions separate from radio access functions 

• The same network should support a variety of access choices, and access technologies may evolve further. 
Therefore network functions such as call control service control, etc. should remain separate from access 
functions and ideally should be independent of choice of access. This implies that the same CN should be able to 
interface with a variety of RANs. 

• See also principle 4 on mobility functions. 

3) Separate functions that are likely to evolve independently 

The following are examples of major functions that may need to evolve independently and would therefore benefit from 
being separate entities in the architecture model. Further discussions are needed to establish an agreed list. 

Bearer control in both access and network 

• Call control for circuit-mode services, call state model 

• Session control for packet-mode services 

• Mail services control 

• Multimedia control for multimedia sessions 
Switching and routing 

Service control and service capabilities, VHE for roamers 

• Service features and applications 

Mobility management and location-based services, mobility state model 

• Security functions 

4) Break down mobility management into a set of independent functions 

Mobility management will be a complex function in R'OO. By breaking it down into independent components it will 
become more manageable. The list below is a suggested breakdown: 

Macro Mobility : Location of the terminal in terms of the network that they are in. The terminal may be within 
any wireless or fixed network. This would be tracked within the UMS function of the HSS . 

; Micro..niQMli.^ 

5) Separate data storage into the following: 

Data storage entities may be needed in different numbers and/or different configurations. Separation of data storage into 
some major categories as listed below, provides that flexibility. 

Location data and authentication data, this may apply only to mobile users 

Service data, charging data, encryption, this may apply to both fixed and mobile users 

USIM data (this is data which is stored within the USIM) 

OA&M data, for both circuit-mode and packet-mode 

• Store and forward mail services 

• Store and forward for content servers e.g. websites 

6) Allow for evolution of numbering and addressing 



This is necessary since IP addressing capacity and IP routing may evolve for the packet switched domain. There 
may be a partial dependence between addressing and routing to allow routing shortcuts. 

• Telephone numbering plan will continue in the circuit switched domain. 

7) Minimize transcoding of traffic 

• This is done to improve end-to-end transmission quality and to facilitate QoS control functions. 

8) Minimize redundant traffic over the radio interface 

• This is necessary r since radio resources are always scarce. Techniques may include stripping packet headers over 
radio links to save radio resources. Seek maximum occupancy of radio bearers with packet multiplexing. 

• Minimize signalling traffic between user and network. 

• Minimize need for re-transmissions between user and network. 

3. Proposals 

It is proposed to revise TR23.821 version 0.1.0 by using material given in sections 1 and 2 above, and adapting 
appropriately for inclusion in the TR: 

• Section 2: Add references listed in section 1 above. 

• Section 3: Add de finitions given in section 2. J above. 

• Add a new' section 5 "Architectural requirements" and renumber subsequent sections. Put section 2.1 above into 
the new section 5. 

• Section 5: Renumber as section 6: Put section 2.2 above "The architecture principles for R '00" into a separate 
subsection. 
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1. Introduction 

The basic assumption for any QoS scheme to work is that a user/application must have 
sufficient permission to request and receive its QoS guarantees. The basic principles and 
requirements as well as the work items of supporting QoS control policies in UMTS have been 
identified in the last 3GPP S2 meeting (24-28 Jan. 2000). One of the key requirements has been 
achieving agreement on a generic definition of UMTS QoS policies that apply to the UMTS QoS 
services. In addition to QoS Policies, there are different policies such as security, address 
management, network topology management and routing policies to name a few, the definition of 
UMTS QoS Policies refers to the policies that apply to the UMTS QoS control, specifically, the 
rules and conditions that govern the access to the UMTS network resources that are allocated 
and managed to deliver the user and/or application requested specific QoS. It is recognized that 
the defined UMTS QoS Policies and the associated UMTS QoS Framework should 



• allow efficient use of UMTS network resources, in particular, the radio resources 
across the air interface between the mobile terminal and the radio access network. 

• support existing and future QoS control mechanisms in both radio access network 
and the core network. 

• be generic and flexible to support different vendors' UMTS networking equipment and 
operators' service requirements. 

• inter-operate with the generic QoS Policies models that are deployed in the external 
networks. 



This document aims to provide an analysis of some application scenarios for UMTS QoS Policies 
and then proposes a UMTS QoS Policy definition for R00 for approval by S2. The definition of the 
UMTS QoS Policy is intended to be generic enough to be applicable to different vendors' QoS 
provisioning mechanisms, different the operators' bilateral/multi-lateral service requirements and 
suitable for different user/application specific QoS requests. This document intends to facilitate 
the definition of a UMTS QoS Policy framework. 



2. The Level of Abstraction of UMTS QoS Policy Definition 

There are can be different levels of abstraction for the UMTS QoS Policy definition. The 
definition can be of a high level abstraction such as the policies that define the service 
level agreements. For example, the UMTS QoS Policy can be defined broadly as the 
administratively prescribed rules and the conditions that are used to govern the bilateral 
service access between different operators' domains by specifying that traffic from 
operator B s s UMTS network domain to the local domain of operator A's can use up to 
20% of the capacity of the operator A* total network links to the external networks, 
regardless of the specific services classes and their QoS requirements of the traffic from 



the operator B. This business level abstraction of UMTS QoS policy, in general, provides 
a rule for the UMTS resource access between different network operators. 



On the contrary, a QoS control policy can be as specific as being applied to per- 
user or per-device. For example, a user QoS policy can set the resource access rule as 
that the traffic from User A running an application of Conversational QoS Class is entitled 
an DSCP value up to 7 and the maximum bit rate of 1 .5 Mbps. This user-specific QoS 
control policy controls a user and/or an application's access right to the UMTS network 
resources within an operator's domain. A per-network device QoS Policy can define the 
queueing management policy to be that a system warning message is generated and 
sent to the QoS Policy Control Element (e.g. the Policy Decision Point) if the queue depth 
is filled up to 90% of the total length. 

In general, different levels of abstractions should be accommodated in the definition of 
UMTS QoS Policies. In addition, differences in terms of QoS policy application 
scenarios, resource cost, utilization and the access mechanisms also need to be 
reflected in the definition but expressed at different abstraction levels that can 
subsequently be classified into different QoS Policy categories. 



3. The Definition of UMTS QoS Policies 

A UMTS QoS policy, in general, is defined as a set of administratively prescribed and negotiated 
rules and agreements that are enforced to control the access to the resources related to the QoS 
provisioning in UMTS networks as well as between UMTS networks and the external netowrks. 

A UMTS QoS policy can be taken as a function with parameters, e.g. user/domain identity, QoS 
requirement, time-of-the day, etc. that are combined with certain rules and conditions applied to 
generate an unambiguous response to a certain resource access/reservation request. To reflect 
different levels of abstraction for the definition, while in the mean time, maintain the basic 
requirements identified in Section 1 and 2, UMTS QoS Policies can be classified into following 
categories. To better explain the QoS Policy categories, the service types, such as the 
Guaranteed Service and the Controlled Load Service, of Integrated Services QoS Framework 
and DiffServ QoS Framework of IETF are used. The proposed QoS Policy categories are 
intended to apply to other QoS Frameworks as well. 



(1) Service Driven QoS Policies: 

Service Driven QoS Policies are defined to be the QoS Policies that are defined and enforced 
according to the QoS Service Classes (Conversational, Streaming, Interactive and Background 
Classes) defined in TS23.107. A Service Driven QoS Policy applies to the resource reservation 
requests from all the users/applications that require the same QoS Class even when they are 
located in different operators' domains using different vendors' network equipment. A Service 
Driven QoS Policy can be subsequently derived from the Service Level Agreement (SLA) 
between the users and their service providers and between service providers. A resource 
reservation request that is governed by Service Driven QoS Policies is expected to be processed 
in the same way and, if it is accepted, achieve the same QoS delivering behavior, regardless of 
the identity and location of the user and the different operational domains of operators. 

Service Driven QoS Policies aim to facilitate the achievement of consistent and unified end-to- 
end resource access and reservation control for the same type of services across different UMTS 
administrative domains. As an example, the Service Driven QoS Policies derived from the 
bilateral or multi-lateral SLAs between different Service Providers (SPs) decide that a user that 



intends to initiate a VoIP call of the Conversational QoS Class should expect the same services 
and thus the consistent call quality when he roams to networks operated by different operators, 
unless the user is entitled for different levels of services, e.g. as a premium user in one operator's 
domain and an economy user in all other domains. 



(2) User/Application Driven QoS Policies: 

User/Application Driven QoS Policies aim to differentiate the UMTS resource access, resource 
reservation and thus the level of QoS based on the identity of the user and/or the nature of an 
application. Users and their applications under different SLAs signed with their SP's are entitled 
for different QoS policies and thus will be treated differently in terms of the eligible resource 
reservation, the level of QoS and charging rates, etc. As an example, user A, if identified as an 
economy user in its SLA with its SP, is allowed Guaranteed Services only during the off-peak 
hours. It is only allowed Controlled Load Service or Best-Effort Seivice during the peak hours, 
regardless of its location and the nature of the applications (Conversational, Streaming, 
Interactive and Background Services) it is running. An example for application driven QoS 
Policies is that all calls to the Tourist Information Office will be provided only Controlled Load 
Service during the off-peak hours and the Best-Effort Service during the peak hours. 

User Driven and Application Driven QoS Policies can be combined to generate the appropriate 
QoS Policies in some application scenarios. Take the same user, A, in the above example. An 
emergency call from all users, including user A, shall be given the Guaranteed Services even 
during the peak hours. 



(3) Network Driven QoS Policies 

Network Driven QoS Policies are referred to the policies that decide the resource access, 
allocation and reservation, specifically, for Capacity and Call Admission Control, in each UMTS 
QoS network element including UE, UTRAN, the Edge Node (SGSN) and Gateway Node 
(GGSN). The semantics of the Network Driven QoS Policies are network element dependent. 
For example, UTRAN interprets and implements the QoS Policies based on radio specific 
resource access allocation and reservation requirements that are different from the QoS Policies 
implemented in the Core Network (SGSN/GGSN). In addition, different Network Driven QoS 
Policies mechanisms need to be implemented for different QoS Frameworks and the QoS 
signaling such as the RSVP/lntServ and DiffServ that deploy different QoS control mechanisms. 

For those network elements such as UTRAN/SGSN/GGSN that deploys DiffServ QoS model, the 
network edge node(s) and the core network node(s) are the two primary locations where the QoS 
Policies are applied. Specifically at the core network nodes, the main QoS Policies are about 
those on accessing the resources (queue/class allocation) while at the edge nodes, the QoS 
Policies for those additional functionality such as flow classification, policing, RSVP message 
processing (mapping), remarking and billing, etc, should be taken into account. 

As a simple example, a Network Driven QoS Policy for allocating the GTP tunnel between the 
SGSN and GGSN that deploy the DiffServ QoS Framework mandates that all user packets are 
marked with a DSCP value of no higher than 7 except for those packets for network control and 
management signaling. 

In comparison, a QoS control Policy for an RSVP capable network element makes it imperative 
that any specific bandwidth reservation request as carried by the RSVP messages (e.g. RESV) 
shall not exceed the Maximum Bit Rate of 1500 kbps. 



(4) Mutual Dependencies of UMTS QoS Policies 

The three UMTS QoS Policy categories are not orthogonal to each other. A UMTS QoS Policy 
decision may well be the result of combining a number of policies that belong to different 
categories. Each type of policy may generate a specific response to the same UMTS resource 
access and reservation request but decisions derived based on the policies from different 
categories should not contradict each other. This unambiguity of UMTS QoS Policy decisions 
must be guaranteed through an appropriate management of the QoS Policy Entities in a UMTS 
QoS Policy Framework. 

(5) Other QoS Policy Dependencies 

The three categories of UMTS QoS Policies may also have other dependencies such as the 
temporal and geographical dependencies. A QoS Policy may be dynamically adapted according 
to the time-of-the day and the change of the user location and therefore, result in different 
responses to the same resource access/reservation request. 



4. Proposal 

It is proposed that the following text is included in Section 9 "QoS" of TR 23.821 . 
The General Requirements for UMTS QoS Policy Control 



UMTS QoS Policies, the UMTS QoS Framework and the UMTS QoS 
Policy control mechanisms should 



• allow efficient use of UMTS network resources, in 
particular, the radio resources across the air interface 
between the mobile terminal and the radio access 
network. 

• support existing and future QoS control mechanisms in 
both radio access network and the core network. 

• be generic and flexible to support different vendors' 
UMTS networking equipment and operators' service 
requirements . 

• inter-operate with the generic QoS Policies models that 
are deployed in the external networks . 



The UMTS QoS Policies 

A UMTS QoS policy is defined as a set of administratively 



prescribed and negotiated rules and agreements that are 



enforced to control the access to the resources related to 
the QoS provisioning in UMTS networks as well as between 
UMTS networks and the external netowrks . 

A UMTS QoS policy can be taken as a function with 
parameters, e.g. user/domain identity, QoS requirement, 
time-of -the day, etc. that are combined with certain rules 
and conditions applied to generate an unambiguous response 
to a certain resource access/reservation request. To 
reflect different levels of abstraction for the definition, 
while in the mean time, maintain the basic requirements UMTS 
QoS Policies can be classified into following categories. 
The UMTS QoS Policies and the associated control mechanisms 
shall support generic QoS frameworks such as Differentiated 
Services QoS Framework of IETF. 

(1) Service Driven QoS Policies: 

Service Driven QoS Policies are defined to be the QoS 
Policies that are defined and enforced according to the QoS 
Service Classes (Conversational, Streaming, Interactive and 
Background Classes) defined in TS23.1Q7. A Service Driven 
QoS Policy applies to the resource reservation requests 
from all the users/applications that require the same QoS 
Class even when they are located in different operators' 
domains using different vendors' network equipment. A 
Service Driven QoS Policy can be subsequently derived from 
the Service Level Agreement (SLA) between the users and 
their service providers and between service providers. A 
resource reservation" request that is governed by Service 
Driven QoS Policies is expected to be processed in the same 
way and, if it is accepted, achieve the same QoS delivering 
behavior, regardless of the identity and location of the 
user and the different operational domains of operators. 

Service Driven QoS Policies aim to facilitate the 
achievement of consistent and unified end-to-end resource 
access and reservation control for the same type of 
services across different UMTS administrative domains . 



(2) User/Application Driven QoS Policies: 

User/Application Driven QoS Policies aim to differentiate 
the UMTS resource access, resource reservation and thus the 
level of QoS based on the identity of the user and/or the 
nature of an application. Users and their applications 
under different SLAs signed with their SP's are entitled 
for different QoS policies and thus will be treated 
differently in terms of the eligible resource reservation, 
the level of QoS and charging rates, etc. User Driven and 
Application Driven QoS Policies can be combined to generate 
the appropriate QoS Policies in some application scenarios. 



(3) Network Driven QoS Policies 

Network: Driven QoS Policies are referred to the policies 
that decide the resource access, allocation and 
reservation, specifically, for Capacity and Call Admission 
Control, in each UMTS QoS network element including UE, 
UTRAN, the Edge Node (SGSN) and Gateway Node (GGSN) . The 
semantics of the Network Driven QoS Policies are network 
element dependent. For example, UTRAN interprets and 
implements the QoS Policies based on radio specific 
resource access allocation and reservation requirements 
that are different from the QoS Policies implemented in the 
Core Network (SGSN/GGSN) . In addition, different Network 
Driven QoS Policies mechanisms need to be implemented for 
different QoS Frameworks and the QoS signaling such as the 
RSVP and DiffServ that deploy different QoS control 
mechanisms . 

For those network elements such as UTRAN/SGSN/GGSN that 
deploys DiffServ QoS model, the network edge node(s) and 
the core network node(s) are the two primary locations 
where the QoS Policies are applied. Specifically at the 
core network nodes, the main QoS Policies are about those 
on accessing the resources (queue/class allocation) while 
at the edge nodes, the QoS Policies for those additional 
functionality such as flow classification, policing, RSVP 
message processing (mapping) , remarking and billing, etc, 
should be taken into account . 



(4) Mutual Dependencies of UMTS QoS Policies 

The three UMTS QoS Policy categories are not orthogonal to 
each other. A UMTS QoS Policy decision may well be the 
result of combining a number of policies that belong to 
different categories. Each type of policy may generate a 
specific response to the same UMTS resource access and 
reservation request but decisions derived based on the 
policies from different categories should not contradict 
each other. This unambiguity of UMTS QoS Policy decisions 
must be guaranteed through an appropriate management of the 
QoS Policy Entities in a UMTS QoS Policy Framework. 



(5) Other QoS Policy Dependencies 

The three categories of UMTS QoS Policies may also have 
other dependencies such as the temporal and geographical 
dependencies. A QoS Policy may be dynamically adapted 
according to the time-of-the day and the change of the user 
location and therefore, result in different responses to 
the same resource access/reservation request. 
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INTRODUCTION 



RSVP is one of the possible mechanisms used by an application in the TE to negotiate 
QoS and activate IP QoS control. The RSVP signaling protocol may be used for the QoS 
control in the local IP access network, or it may be used end-to-end across IP 
networks. 

For the case where RSVP is used to perform QoS control in the local IP access network, 
RSVP signaling will be terminated at the MT and PDP context procedures will be used 
for UMTS control in the UMTS network. 

In addition, RSVP signaling may be used in an end-to-end mode. In this mode, TE and 
its remote peer running RSVP (located within the external network) will exchange RSVP 
signaling messages to set up RSVP sessions. Periodic RSVP refresh messages are 
used to maintain the RSVP sessions. But such periodic transmission of RSVP 
messages increases the traffic load within UMTS networks, in particular, over the air 
interface. 

The general requirements for supporting RSVP applications in UMTS network are: 

• No change to standard RSVP applications 

• No or minimal impact on existing UMTS network architecture, and QoS control 
procedures. 

• Minimize any extra signaling traffic associated with supporting RSVP applications. 

In this document, we describe two application scenarios where RSVP is used to 
negotiate QoS and activate QoS control across UMTS networks. The two scenarios 
are: 

Scenario I: RSVP signaling is terminated at the MT only 

Scenario II: RSVP signaling is terminated at both MT and GGSN only. 



The advantages with this function performed at the MT are summarized: 



• The MT can be upgraded quicker to cater for new features in the QoS control API. 

• Allows access independent API at the application level. 

• Allows interface specific controls to override non-interface specific settings for non- 
mobile aware applications. 

• Allows tight customer control of expensive radio resources 

• Allows appropriate control of the radio access regardless of whether it is an IP 
service or a PPP service being provided. 

• The MT under the control of the end application can determine by using RSVP 
whether to modify an existing PDP context or create a new PDP context to provide 
the QoS needs of each RSVP session. 

In contrast to the approach proposed in [1] for the end-to-end mode, it is proposed to 
include the general requirements on supporting some generic non-UMTS QoS signaling 
schemes such as RSVP and the schemes to restrict the processing of RSVP, or in 
general, the non-UMTS QoS signaling message at the edge of UMTS network by using 
the PDP context request/response messages. 
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Figure 1 : QoS management functions for UMTS bearer service in the control plane 



When the application is using RSVP to control QoS at the IP level, the MT must examine 
the RSVP messages to gather information about the application's QoS requirements. 
The MT may then override/modify the QoS parameters according to the user specific 
configuration. The resultant parameters are then used to activate and/or modify the 
PDP context to support that QoS request. Note that MT is also required to check if the 
RSVP messages are (a) sent/received the first time so as to initiate PDP context setup, 
(b) modified in order to initiate PDP context modification procedure) or (c) merely 
refresh messages to trigger local generation of responses. 

An RSVP processing entity -within the MT will receive and act on the RSVP signaling. It 
is a local configuration decision whether the MT will 



.1. Intercept the RSVP signaling, process and relay RSVP messages 
2. Intercept the RSVP signaling, and initiate an RSVP proxy to improve the reliability 
and efficiency of RSVP across the radio interface. 

These two scenarios are depicted in the figures below, for the uplink/downlink cases 
where the PATH message is received from the TE (for uplink traffic QoS control) , and 
from the external network (for the downlink Traffic QoS control). 

Note: The two scenarios assume the termination of RSVP signaling in MT. The 
functional split between MT and TE is a local configuration, other functional split of the 
MS/UE shall therefore also be possible. 



2 SUPPORTING RSVP IN UMTS 



2. 1 SCENARIO 1 : MT TERMINATED RSVP 

It is recognized that Scenario 1 is applicable for an MS/UE using RSVP to communicate 
with a Non-RSVP application in either an MS or a fixed terminal .In this scenario, the 
RSVP signaling is terminated at MT as shown in Figure 2. 
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ure 2: MT Terminated RSVP: TE as the RSVP sender 



For the traffic QoS control in the uplink direction as shown in Figure 2, when the PATH 
message is received from TE, the MT analyzes the RSVP parameters carried in the 
PATH message, and determines whether to create a new secondary PDP context, or to 
modify an existing one for an updated QoS status. The secondary PDP context is then 
created/modified using the existing PDP Context Control procedures. If the PATH 
message is a first-time PATH message, a new secondary PDP context needs to be 
created. If the PATH message is a refresh message with no modified QoS parameters, 
then no action will be taken (no PDP context modification is required). MT will generate 
the refreshed RESV message to the TE. 



Upon successful establishment of a secondary PDP context, the MT can instantiate an 
RSVP proxy to terminate RSVP signaling messages. In this mode, the RSVP proxy is 
responsible for receiving and processing the PATH message(s), and generating the 
RESV message(s) as a response. 
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Figure 3: MT Terminated RSVP: External IP Host as the sender 

We assume that RSVP is used by MT/TE to reserve local IP access network resource. 
For the traffic QoS control in downlink direction as shown in Figure 3, in order to 
initiate the RSVP PATH message for the TE, the RSVP Processing Entity at the MT 
needs to be triggered as a result of either receiving network initiated secondary PDP 
context modification requesting for an updated QoS or network- requested PDP Context 
Activation. GGSN will initiate the network initiated PDP context procedure if it receives a 
PDU. 



As a response to the PATH message sent from MT, the TE sends an RESV message 
to the MT which, in turn, decides if a secondary PDP context should be modified or 
created. 



Scenario 1 can also be used for the case where an RSVP-capable TE communicates 
with an RSVP-capable host in external network. In that case, all RSVP control messages 
will be intercepted by MT assuming that primary PDP context (best-effort context) is set 
up between MT/GGSN for this communication. MT will then do the secondary PDP 
context negotiation. So GGSN does not have to interpret RSVP control messages. 



2.2 SCENARIO 2 



In this scenario, the RSVP session is used end-to-end and terminated at the MT and the 
GGSN. The assumption is that the TE intends to set up RSVP session with its remote 
peer that also uses RSVP signaling in the external network. Figure 4 shows the RSVP 
activated QoS Control in the uplink direction. 
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Figure 4: MT and GGSN Terminated RSVP: TE/MT as the RSVP sender 

In this scenario, when the MT receives the PATH message from TE, MT checks to see if 
a PDP context exists for this RSVP session. If it does, MT triggers the Modify/Create 
SecondaryPDP context message if there is a change in QoS parameters or if a 
secondary PDP context needs to be created. The PATH message is piggybacked on the 
Activate/Modify PDP context Request messages using the PDP config. option. (Note 
that an alternative solution is to extract the Traffic Specs such as the Tspec, ADSpec 
from the PATH message and piggyback them using the PDP config. option to the 
Activate/Modify PDP Context Request messages). Alternatively, the PATH message can 
be sent as regular network PDU using the existing primary PDP context. Note that MT is 



expected to populate the Requested QoS IE based on the PATH information. SGSN can 
use the information within the Requested QoS IE to do RAB negotiation with UTRAN. 
The PATH message will be relayed to GGSN. The GGSN extracts the PATH message 
and then relays it to the external network. 

Note that GGSN can generate the PDP context response without waiting for the RESV 
message. However, with that approach, GGSN may not be able to populate the 
Negotiated QoS IE with values that matches RESV QoS requirements. Figure 4 shows 
that the GGSN waits for RESV before generating the PDP context response message. 

When the RESV response is received at the GGSN, it uses this information, along with 
relevant local configuration, to see if QoS Negotiated is the same as QoS Requested. 
Then it piggybacks the RESV message on the Activate/Modify PDP Context response 
message using the PDP config. option. RAB re-negotiation can take place between 
SGSN and UTRAN if QoS Negotiated is different from QoS Requested. Finally the 
RESV message possibly adapted at the GGSN is sent on to the TE by piggybacking on 
the Activate /Modify -PDP Context Confirmation message(s). This proposed 
piggybacking of RSVP messages/Traffic &QoS Data Objects on PDP Context control 
messages aims to speed up the end-to-end QoS negotiation process. 

Note that the current PDP context procedure as discussed in 23.060 mandates SGSN to 
perform RAB negotiation upon receiving the PDP context request message. For the 
scenarios where end-to-end QoS is negotiated using RSVP, such procedures mean 
SGSN may need to do RAB re-negotiation. 
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Figure 5: MT and GGSN Terminated RSVP: TE/MT as the RSVP receiver 



The case shown in Figure 5 depicts the situation for the QoS control in the downlink 
direction where no corresponding PDP context exists when the PATH message is 
received at GGSN. GGSN will send a PDU notification request message to SGSN. 
SGSN will respond with a PDU notification response and send a request PDP context 
activation message to the MT. To speed up the negotiation of a PDP context, GGSN 
piggybacks the PATH message on the PDU Notification Request message and the 
Request PDP Context Activation message so that the PATH message can be delivered 
faster to the TE waiting for the PDP context to be set up. It reduces the extra latency of 
the RSVP QoS negotiation process caused otherwise by sending the RSVP messages 
separately across the air interface and the UMTS network. The usage of proxies at 
MT/GGSN to process future PATH/RESV messages helps to minimize extra traffic load 
across the UMTS network, in particular, over the air interface. 

An alternative to piggybacking the RSVP messages in the secondary PDP Context 
Activation/Modification messages is to carry Tspec/ADSpec objects in the secondary 
PDP Context Control messages using the PDP Config Option. 

When the PATH message or the TrafficSpecs (Tspecs , Adspecs) is received by the MT, 
it is passed along to the TE. When the TE responds with the RESV message, the MT 
may make some modifications on the parameters according to the local configuration, 
then initiate the Activate the secondary PDP Context procedure. The RESV message or 
the QoS Specs (such as the FlowSpecs) is piggybacked on the message to the GGSN 
using the PDP config. option. When GGSN receives the Create Secondary PDP 
Context Request, it extracts the RESV message and relays it to the external network. 

For subsequent refresh RSVP messages, proxies can be used at MT and GGSN to 
locally generate the PATH/RESV messages (shown as the last set of messages in 
Figure 5). When there is no change in RESV message, MT will not relay it across the 
airlink. When there is no change in PATH message, GGSN will not relay it across the 
airlink. 



3 PROPOSAL 

It is proposed that the general requirements and the two working scenarios to meet the 
requirements for supporting RSVP in UMTS are included in the QoS section of 
TR23.821. The suggested texts are as follows: 



The General Requirements for Supporting RSVP in UMTS Network 



The general requirements for supporting RSVP applications in UMTS 

network are: 

• No change to standard RSVP applications or operating systems . 

• No or minimal impact on existing UMTS network architecture, and QoS contro l 
procedures. 

• Minimize any extra signaling traffic associated with supporting RSVP applications . 



• The QoS control in UMTS network does not rely on the RSVP QoS Status, i.e. the 
soft states. 

The Working Scenarios for supporting RSVP in UMTS 

Two possible working scenarios are recognized for supporting 

Applications/MS/UE that uses RSVP to activate QoS control: MT Terminated RSVP 
Signaling and MT and GGSN Terminated RSVP Signaling . 

Scenario I, MT Terminated RSVP signaling, is applicable to an MS/UE 

using RSVP to communicate with a Non-RSVP application in either an MS or a fxied 
terminal. The uplink/downlink traffic QoS control using an MT Terminated RSVP 
signaling is shown in Figure 2 and 3, respectively. It is also applicable for the case where 
an MS/UE using RSVP to communicate with a RSVP-capable host in external network . 
For this later case, GGSN is oblivious of all the RSVP messages. This later case wil l 
incur more delay in end-to-end QoS negotiation than the approach proposed in Scenari o 
II 

Scenario II, MT and GGSN Terminated RSVP signaling, is applicable to the 

working scenario where the TE intends to set up RSVP session with its remote peer tha t 
also uses RSVP signaling across the external network. The uplink/downlink traffic QoS 
control using an MT Terminated RSVP signaling is shown in Figure 4 and 5 , 
respectively. 



To simplify the network control and efficiently utilize the UMTS radio and 

network resources, it is recommended that RSVP messages are not interpreted by the 
UTRAN or the SGSN or transmitted separately across the UMTS network, in particular , 
across the air interface. An approach using the PDP config option within the existing 
(secondary) PDP Context Control messages may be used to deliver first-time RSVP 
message related information across the UMTS network. Proxies can be used to locally 
generate refreshed RSVP messages to minimize extra usage of airlink . 
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1. Introduction 

Annex G of the H. 225.0 Recommendation describes methods to allow address resolution, access 
authorization and usage reporting between administrative domains in H.323 systems' for the 
purpose of completing calls between the administrative domains. An administrative domain 
exposes itself to other administrative domains through a type of logical element known as a 
Border Element. The Border Element is a functional element that supports public access into an 
administrative domain for the purposes of call completion or any other services that involve 
multimedia communication with other elements within its administrative domain. The Border 
Element controls the external view of the administrative domain. 



2. Definitions 

Wireless Administrative Domains 

For wireless applications the Administrative Domains may be defined as follows: 

• Home Administrative Domain is the Administrative Domain that is related by subscription to 
the mobile H.323 network user. The Home Administrative Domain permanently contains user 
specific data including location, authentication, and service profile information related to the 
mobile H.323 network user. 

• Visited Administrative Domain is the Administrative Domain that is not the Home 
Administrative Domain and is serving an active mobile H.323 network user. 

• Serving (Visited or Home) Administrative Domain is the Administrative Domain that is serving 
an active mobile H.323 network user. 



3. Discussion 

Border Elements for Wireless Administrative Domains 

The Border Element's call-routing function as defined in the Annex G of the H.225.0 
Recommendation can be logically divided into two disjoint functions. The first function pertains to 
address resolution for the calls that originate in its Administrative Domain. The second function 
pertains to address resolution for the calls that terminate in its Administrative Domain. For the 
current landline applications (i.e. excluding number portability) the sets of H.323 terminals that 
are handled by these two functions are identical. 

However, for wireless applications the two Border Element's functions identified above will be 
logically separated and incorporated into two disjoint logical entities referred to as the Home 
Border Element and the Serving Border Element (see Figure 1). 

Home Border Element 

A Home Administrative Domain will expose all its subscribers - irrespective of their current 
location - to other administrative domains through a new type of logical element referred to as the 
Home Border Element . A Home Border Element is a functional element that supports public 
access to mobile H.323 terminals that belong to its Home Administrative Domain - for the 
purposes of call completion - irrespective of their location. The Home Border Element will 



3 GPP TSG-SA WG2 #12, 6-9 th March 2000 s2-(00)0369 
Tokyo, Japan 

communicate with other Border Elements using the protocol that is specified in Annex G of the 
H.225.0 Recommendation. 




Home Subscriber Server (HSS) Description 

To provide services to the roaming wireless mobile 3G terminals, a new 3G functional entity, 
referred to as the Home Subscriber Server , has been identified. The Home Subscriber Server is a 
functional entity that is located in the Home Administrative Domain and contains a record for each 
home subscriber that includes location information, subscriber status, subscribed features, 
aliases, and directory numbers. In addition, for each roaming mobile H.323 terminal the Home 
Subscriber Server will also include in the record a list of all Call-Processing entities (i.e.CSCFs 
and Gateways) in the Serving Administrative Domain that may handle the incoming calls destined 
for the roaming mobile H.323 terminal. For each listed entity, the following information may be 
included: 

• Identity and the type of the Call processing entity in the serving network that may handle the 
incoming calls for the visiting mobile H.323 terminal (e.g. H.225 Gatekeeper, SIP-to-H.323 
Gateway, and PSTN-to-H.323 Gateway). 

• Network Address, the protocol (TCP/UDP), and the port number where the call processing 
messages should be sent. 

• Priority. The priority information specifies the order in which the multiple call-processing 
functional entities should be tried. 

The Serving Administrative Domain (e.g. visited CSCF) will provide this list to the Home 
Subscriber Server when the roaming wireless mobile H.323 terminal registers with the Serving 
Administrative Domain (i.e. during the RAS procedure). Upon each re-registration within the 
current Serving Administrative Domain or with a new Serving Administrative Domain, a new list 
will be conveyed to the Home Subscriber Server. 

Home Border Element Operations 

The Home Border Element will maintain two types of address templates. The first type will be 
advertised to other Border Elements and Clearing Houses. In the advertised address-templates 
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the .Home Border Element will indicate the set of alias addresses (e.g. email-ids and party 
numbers) that it can resolve. The advertised templates will be marked "Send Access Request to 
the Home Border Element 1 and will indicate that the "Call Specific authorization is requested for 
each call" Other Border Elements and Clearing Houses may cache these templates. 

With respect to second type of templates, the Home Border Element will maintain an address 
template for each roaming mobile H.323 terminal that belongs to its Home Administrative 
Domain. This address template will be dynamically updated upon each mobile H.323 terminal's 
registration and re-registration with the visited network. Its Home Subscriber Server will convey 
the update-information to the Home Border Element . This template will also indicated that a 
Setup message (rather than the Access Request message) should be sent to the indicated 
contact. When responding to the request to resolve an Alias Address the Home Border Element 
will explicitly indicate that the supplied information should not be cached. These address 
templates will not be advertised. 

The Home Border Element will communicate with other entities within its Home Administrative 
Domain (e.g. the Home Subscriber Server) or it may exist in combination with other H.323 
elements. In most implementations the Home Border Element will be combined with the Home 
Subscriber Server. 



Serving Border Element 

A Serving Border Element is a functional element that is located in the Serving Administrative 
Domain and provides address resolution for the visiting mobile H.323 terminals for the purpose of 
completing the calls that originated in its Serving Administrative Domain. The Serving Border 
Element communicates with other Border Elements (including the Home Border Elements) and 
the Clearing Houses using the protocol specified in Annex G of the H.225.0 Recommendation. In 
addition, the Serving Border Element may - depending on implementation - communicate with 
other entities within its Serving Administrative Domain. The Serving Border Element may exist in 
combination with other H.323 elements (e.g. a combination of Border Element and CSCF). 



4. Conclusion 

This contribution proposes that the address resolution architecture for Wireless H.323 
Administrative Domains described in this contribution be discussed and adopted by the 3GPP 
WG S2. 
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1. Discussion 

The wireless 3G all-IP network will employ a layered IP architecture. For this architecture, the IP 
plane will extend to all mobile IP terminals. There will be a number of application-level services 
(e.g. Voice over IP) that will be supported by the underlying IP plane. In the assumed layered 
architecture, the multimedia H.323 Call-Control service should be viewed as an application-level 
service that executes in the H.323 Call-Control plane. The H.323 Call-Control plane will extend 
only to the mobile H.323-capable terminals. This contribution advocates that the H.323 Call- 
Control plane should be partitioned into Domains. It can be argued that all mobil elP terminals will 
roam across the IP plane and that their IP-locations in the IP plane will be IP-monitored (e.g. RA, 
SGSN). However, since the mobile H.323 terminals will also roam in the H.323 Call-Control 
plane, their location in H.323 Call-Control plane (i.e. their Domain-location) should be monitored 
as well. The same mechanism (i.e. HSS) that is employed to monitor the location of the mobile IP 
terminals in the IP plane should be utilized to monitor the location of the mobile H.323 terminals 
in the H.323 Call-Control plane. 

There will be at least one CSCF in each Domain. However, in many cases there will be a number 
of CSCF-entities in each Domain that will be able to handle the RAS-registration and call- 
processing functions for the visiting mobile H.323 terminals. All of theseCSCFs will belong to the 
same multicasting group and share a unique multicast IP address. As the mobile H.323 terminal 
roams from one visited Domain into another, it should dynamically acquire a new IP address in 
the next visited Domain and subsequently execute the RAS-registration procedure. Hence, all 
calls and associated information flows that are destined for the mobile H.323 terminal will be 
routed directly to the next visited Domain. This will require each SGSN in a visited Domain to 
have a logical association with a GGSN in a visited Domain that provides the CSCF services. 
Furthermore, the mobile H.323 terminal - on PDP context setup - would identify the service 
required as "H.323" services and the SGSN would always choose the default GGSN 
(geographically closest) in a visited Domain for servicing that mobile H.323 terminal. 

If a H.323 call is established when the mobile H.323 terminal is in a given visited Domain, the 
CSCF-entity initiating the call should be the "anchor" CSCF-entity that will handle the call during 
its entire duration. In addition, the IP address that was used when establishing the call should be 
the "anchor" IP address used to route the IP packets to the mobile H.323 terminal during the 
entire duration of the call. The "anchor" IP address should be utilized irrespective of the mobile 
H.323 terminal roaming into the next visited Domain during the duration of the H.323 call. The 
underlying IP handover mechanism (i.e. GPRS) will provide connectivity between the "anchor" IP 
address and the mobile H.323 terminal's current location during the entire duration of the call. 
Once the call is cleared, the mobile H.323 terminal will acquire a new IP address and register 
with a new CSCF-entity whenever it enters a new visited Domain. 

The H.323 Call-Control plane will be overlaid on top of the IP plane. Hence, each mobile H.323 
terminal that is GPRS attached always will be located in some Domain. As the mobile H.323 
terminal roams across the IP plane and executes GPRS Routing Area location-updates, it should 
be informed whether the Domain boundaries have been crossed. If the Domain boundary has 
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beea crossed, the mobile H.323 terminal will have to acquire a new IP address and register with 
a CSCF-entity in the new visited Domain. Therefore, a mechanism should be implemented in the 
3G all-IP network that will indicate to the mobile H.323 terminal whenever it has crossed the 
Domain boundaries. This mechanism, for example, may employ the SGSN to inform the mobile 

H. 323 terminal (e.g. in the RA Confirmation message) that it has crossed the Domain boundary. 
Another alternative may be to incorporate the Domain information into the RAI. When crossing 
the Domain boundary, the mobile H.323 terminal does not need to know the identity of the new 
visited Domain. It should be only informed that the Domain boundary has been crossed. 

The mobile H.323 terminal's de-registration procedure in the previously visited Domain may be 
explicitly performed by the mobile H.323 terminal or this task may be executed by the HSS. 

2. Registration Scenario 

The following steps exemplify the RAS-registration procedure for a roaming mobile H.323 
terminal: 

I. Upon entering a new visited Domain, the visiting mobile H.323 terminal will acquire an IP 
address in the visited Domain. The visiting mobile H.323 terminal will maintain this IP address 
during its stay in the visited Domain. 

2. Upon acquiring the IP address, the visiting mobile H.323 terminal will multicast the 
Gatekeeper Request (GRQ) message over the multicast channel. 

3. Multiple CSCFs may respond with the Gatekeeper Confirmation (GCF) message and offer 
the RAS-registration service to the visiting mobile H.323 terminal. Each CSCF should be able 
to indicate its "registration priority" (e.g. "traffic load") in the GCF message. 

4. The visiting mobile H.323 terminal will initiate the RAS-registration procedure by sending the 
Registration Request (RRQ) message to the selected CSCF. 

5. The selected CSCF will inform the visiting mobile H.323 terminal's HSS about its location (it 
will convey to the HSS the IP address of the visiting mobile H.323 terminal). In addition, the 
selected CSCF will also offer its call processing service for the visiting mobile H.323 terminal 
by sending to the HSS the IP address where the call processing messages (destined for the 
visiting mobile H.323 terminal) should be sent. 

6. The HSS may accept the offer or select a different CSCF (e.g. a CSCF in the home Domain). 
If a different CSCF has been selected, the HSS will return to the CSCF (in the visited 
Domain) the IP address of the CSCF (e.g. in the home Domain) that should handle the call 
processing for the mobile H.323 terminal. 

7. The IP address of the CSCF that the visiting mobile H.323 terminal should use when initiating 
a call is sent to the mobile H.323 terminal in the Registration Confirmation (RCF) message. 

3. Conclusion 

This contribution discusses the need for partitioning the Call-Control plane into Domains. It also 
specifies that whenever the mobile H.323 terminal enters a new Domain it should acquire an IP 
address and RAS-register with a CSCF-entity in the respective Domain. In addition, this 
contribution identifies the need for a mechanism to inform the roaming mobile H.323 terminal 
whenever it crosses the Domain boundaries. It is recommended that the material presented in 
this contribution be discussed and adopted by the 3GPP WG S2. 
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5.4.1 



Packet Domain Core Network Nodes 



A GPRS Support Node (GSN) contains functionality required to support GPRS and/or to support UMTS packet 
domain functionality. In one PLMN, there may be more than one GSN. 

The Gateway GPRS Support Node (GGSN) is the node that is accessed by the packet data network due to evaluation of 
the PDP address. It contains routeing information for attached GPRS users. The routeing information is used to tunnel 
N-PDUs to the MS's current point of attachment i.e., the Serving GPRS Support Node. The GGSN may request 
location information from the HLR via the optional Gc interface. The GGSN is the first point of PDN interconnection 
with a GSM PLMN supporting GPRS (i.e., the Gi reference point is supported by the GGSN). GGSN functionality is 
common for GPRS and for the UMTS packet domain. 

The Serving GPRS Support Node (SGSN) is the node that is serving the MS. The SGSN supports GPRS (i.e., the Gb 
interface is supported by the SGSN) and/or UMTS (i.e., the Iu interface is supported by the SGSN). At GPRS attach, 
the SGSN establishes a mobility management context containing information pertaining to e.g., mobility and security 
for the MS. At PDP Context Activation, the SGSN establishes a PDP context, to be used for routeing purposes, with the 
GGSN that the subscriber will be using. 

The SGSN and GGSN functionalities may be combined in the same physical node, or they may reside in different 
physical nodes. SGSN and GGSN contain IP or other (operator^ selection, e.g., ATM-SVC) routeing functionality, and 
they may be interconnected with IP routers. In UMTS, the SGSN and RNC may be interconnected with one or more I P 
routers. When SGSN and GGSN are in different PLMNs, they are interconnected via the Gp interface. The Gp interface 
provides the functionality of the Gn interface, plus security functionality required for inter-PLMN communication. The 
security functionality is based on mutual agreements between operators. 

The SGSN may send location information to the MSC/VLR via the optional Gs interface. The SGSN may receive 
paging requests from the MSC/VLR via the Gs interface. 

The SGSN interfaces with the GSM-SCF for optional CAMEL cost control. Depending on the result from the CAMEL 
interaction, the session and packet data transfer may proceed normally. This also applies if the SGSN does not support 
CAMEL interaction. Otherwise, interaction with the GSM-SCF continues as described in 3G TS 23.078 [8b]. Only the 
GSM-SCF intenvorking points are indicated in the signalling procedures in this specification. 
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According to TS 23.121 v 3.2.0 [3], the SGSN acts as a router for IP packet forwarding 
during the Relocation procedure when the source RNC receives the IP address of the 
target RNC in the 'Relocation Command' message. The source RNC and the target 
RNC are not in the same LIS (Logical IP Subnet), so a routing function is required to 
deliver the data. 

According to TS 25.414 [2] Classical IP over ATM is required at the lu interface when 
PVCs are used. Classical IP over ATM (RFC 2225) [1] allows a router to be a member 
in a LIS, therefore routers are allowed also at the lu interface. 

The following is stated in RFC 2225: 

RFC 2225, Ch. 5.2: 

The requirements for IP members (hosts, routers) operating in an ATM LIS 
configuration are:... 

RFC 2225, Ch. 4: 

"One IP subnet is used for many hosts and routers. Each VC directly connects two 
IP members within the same LIS. " 

RFC 2225, Ch. 5.1: 

"Communication to hosts located outside of the local LIS is provided via an IP 
router. This router is an ATM endpoint attached to the ATM network that is 
configured as a member of one or more LISs. " 
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3.3 Abbreviations 



For the purposes of the present document the following abbreviations apply: 



AAL 


ATM Adaptation Layer 


AESA 


ATM End System Address 


ALCAP 


Access Link Control Application Part 


ARP 


Address Resolution Protocol 


ATM 


Asynchronous Transfer Mode 


RFC 


Request For Comment 


CN 


Core Network 


GTP 


GPRS Tunnelling Protocol 


IP 


Internet Protocol 


LIS 


Logical IP Subnet 


MTP3b 


Message Transfer Part level 3 for Q.2140 


NSAP 


Network Service Access Point 


PDU 


Protocol Data Unit 


RNC 


Radio Network Controller 


SAR 


Segmentation and Reassembly 


SCCF-NNI 


Service Specific Coordination Function-Network Node Interface 


SSCOP 


Service Specific Connection Oriented Protocol 


sscs 


Service Specific Convergence Sublayer 


UDP 


User Datagram Protocol 


VC 


Virtual Circuit 
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6.1.5 IP/ATM 



Classical IP over ATM protocols are used to carry the IP packets over the ATM transport network when PVCs are used. 
Classical IP over ATM is specified in IETF RFC 2225 [15]. Multiprotocol Encapsulation over AAL5 is specified in 
IETF RFC 1483 [14]. 

Classical IP over ATM allows routers to be members of one or more LISs. The CN side of the Iu interface shall provid e 
IP routing functionalities. The RNC side of the Iu interface may provide routing functionalities. If the RNC side of the 
Iu interface does not provide routing functionalities, the RNC routing tables shall include default route entries . 
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In RRC Idle mode it is the broadcasted MM system information (e.g. information about the present Location Area and 
present Routing Area) that determines when the UE initiates a location registration procedure towards the CN. An UE in 
state CS-IDLE will in RRC Idle mode, initiate Location Area update towards the CN when crossing LA border. An UE 
in state PS-IDLE will in RRC Idle mode initiate Routing Area update towards the CN when crossing RA border. 

In RRC Connected mode, the UE receives the MM system information on the established RRC connection. (I.e. the 
broadcasted MM system information is not used by the UE in the RRC connected mode.) An UE in state CS-IDLE will, 
in RRC Connected mode, initiate Location Area update towards the CN when receiving information indicating a new 
Location Area. An UE in state PS-IDLE will, in RRC Connected mode, initiate Routing Area update towards the CN 
when receiving information indicating a new Routing Area. An UE in state CS-CONNECTED will, in RRC Connected 
mode, not initiate Location Area update towards the CN. An UE in state PS- CONNECTED will, in RRC Connected 
mode, not initiate Routing Area update towards the CN. 

In CS-DET ACHED mode the UE will not initiate any Location Area update and this independent of the RRC mode. In 
PS-DETACHED mode the UE will not initiate any Routing Area update and this independent of the RRC mode. 

In additional to normal location registration when changing registration area, the UE may (network options) perform CS 
periodic registration when in CS-IDLE state and PS periodic registration when in PS-IDLE state. The respective 
periodic registration may be on/off on Location Area respective Routing Area level. 

On the Mobility Management level, IMSI and CS related TMSI are used as UE identities in the CS sen-ice domain, and 
IMSI and PS related TMSI are used as UE identities in the PS service domain. The IMSI is the common UE identity for 
the two CN service domains. 

A signalling connection between the UE and the CN refers to a logical connection consisting of an RRC connection 
between UE and UTRAN and an Iu signalling connection ("one RAN AP instance") between the UTRAN and the CN 
node. Hie CS service domain related signalling and PS service domain related signalling uses one common RRC 
connection and two Iu signalling connections ("two RANAP instances")., i.e. one Iu signalling connection for the CS 
sendee domain and one Iu signalling connection for the PS service domain. 

4.3.1.1 Use of combined procedures for UMTS 

The use of separated PS and CS mobility mechanisms within the UE and within the CN may lead to non-optimal usage 
of the radio resource (for example a UE in PS idle and CS idle state would perform both location updates (for the CS 
mechanism) and Routing area updates (for PS mechanisms)). 

UMTS should optimise the use of radio resources., The use of combined updates (similar to the current GSM/GPRS Gs 
combined update mechanism) may enable this. To offer flexibility in the provision of mobility management for UMTS, 
it should be possible to use combined mechanisms for location management purposes as well as for attach/detach status 
purposes. 

From the UE perspective it should be possible for the UE to perform combined update mechanisms (operator option). 
UMTS Phase 1 R99 terminals should support the use of both combined and separate mechanisms. The support of this 
feature by all UMTS mobiles will also ease evolution of UMTS MM in the future. 

In the UMTS specifications the RAN will not co-ordinate mobility management procedures that are logically between 
the core network and the MS. This includes: location management, authentication, temporary identity management and 
equipment identity check. 

The issues of security, temporary identifiers^ CS and PS periodic registrations and PS DETACHED/CS DETACHED 
need to be stud i ed. 
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4.3.2 Description of the Location Management and Mobility Management 
Concept 

4.3.2.1 Area concepts 

For the mobility functionality four different area concepts are used. Location Area and Routing Area in die CN as well 
as UTRAN Registration Area and Cell areas in the UTRAN. 



Area Concepts 
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Figure 4-10: Relationship between different areas. 



4.3.2.1.5 Hierarchical tracking concept 

A packet UE (in RRC connected mode) is tracked at the cell level by RNC during an active connection. 

A packet UE (in RRC connected mode) is tracked at the URA level by RNC when no data are actively transfer, and the 
probability of data transfer is quite high. 

A packet UE (in PS-Idle state) is tracked at the Routing Area level by SGSN when no data is actively transfered and the 
probability of data transfer is quite low.The network operator should be able to optimise paging and updating load by 
controling the size of die different areas and the probability of data transfer (controlled by the RRC_connection_release 
timer). For example, one operator may decide that URA are small and that RRC connection are released after a 
relatively short time of inactivity, so that most attached packet UE are tracked in the Routing Area level (optimum for 
packet UE mainly using client-server type of service). 

Another operator may decide that URA are large, and that RRC connection are released only if RRC connection is lost, 
so that most attached packet UE are tracked at the URA level. 

Different timer values arc required for the URA Update Timer and for the PJfrC Connection Release Timer, It ie fo r 
further ctud} r whether the duration of the P.RC_Connection_Releags timer is eet on a per UE basis, or configurable by 
the operator to be the same for all UE. 

4.3.3 Relationship between MM and SM states for an UE 

When a UE is attached to PS service, it may have or not some PDP context established. 

If the UE has no PDP context established (SM-Inactive) ; no radio access bearer are established for PS sendee. The UE is 
in RRC connected mode, only if the state is UMTS CS-CONNECTED state or UMTS PS-CONNECTED state (i.e. only 
a PS signaling connection is established). 

If the UE has at least one PDP context established (SM-Active), the UE may be in UMTS PS-CONNECTED state or in 
UMTS PS-IDLE state. 
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Figure 4-17: Interface information transfer for location update when changing VLR area 



The RRC connection is established, if not already done. The UE sends the initial message Location Area Update 
Request (old TMSI, old LAI, etc.) to the new 3G__MSC/VLR. The old TMSI and the old LAI are assigned data in 
UMTS. The SRNS transfers the message to the 3GJ4SC/VLR. The sending of this message to 3G_MSC/VLR 
will also imply establishment of a signalling connection between SRNS and 3G_MSC/VLR for the concerned 
UE. The 3G_MSC/VLR determine s the new Location Area for the UE. Whether the 3G jVlSCAfLF. derives th e 
new LAI from information supplied by the UE or by the SP.NS is ffs. The UTRAN shall add the RAC and th e 
LAC of the cell where the message was received before passing the message to the MSC . 

The new 3G_MSC/VLR sends an Send Identification Request (old TMSI) to the old 3G_MSC/VLR to get the 
IMSI for the UE. (The old LAI received from UE is used to derive the old 3G_MSC/VLR identity/address.) The 
old 3G_MSC/VLR responds with Send Identification Ack. (IMSI and Authentication triplets). 

Security functions may be executed. 

The new 3G_MSC/VLR inform the HLR of the change of 3G_MSC/VLR by sending Update Location (IMSI, 
MSC address, VLR number) to the HLR. 

The HLR cancels the context in the old 3G_MSC/VLR by sending Cancel Location (IMSI). The old 
3GJVISC/VLR removes the context and acknowledges with Cancel Location Ack . 

The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_MSC/VLR. The new 
3G_MSC/VLR acknowledges with Insert Subscriber Data Ack. 



The HLR acknowledges the Update Location by sending Update Location Ack. to the new 3G_MSC/VLR. 



• The RRC connection is established, if not already done. The UE sends the initial message Routing Area Update | 

Request (old P-TMSI, old RAI, etc.) to the new 3G_SGSN. The old P-TMS1 and the old RAI are assigned data in 
UMTS. The SRNS transfers the message to the 3G_SGSN. The sending of this message to 3G_SGSN will also 
imply establishment of a signalling connection between SRNS and 3G_SGSN for the concerned UE. The 
UTRAN shall add the RAC and the LAC of the cell where the message was received before passing the messag e 
to the SGSN. 

. The 3G SGSN determines the new Flouting Area for the UE. Whether the 3G SGSN derive thg new RAI from 
information supplied by the UE or by the SRNS i s ff s . 

• The new 3G_SGSN send an SGSN Context Request (old P-TMSI, old RAI) to the old 3G_SGSN to get the IMSI 
for the UE. (The old RAI received from UE is used to derive the old 3G_SGSN identity/address.) The old 
3G_SGSN responds with SGSN Context Response (e.g. IMSI, PDP context information and Authentication 
triplets). 

• Security functions may be executed. 

• The new 3G_SGSN informs the HLR of the change of 3G_SGSN by sending Update GPRS Location (IMSI, 
SGSN number, SGSN address) to the HLR. 

• The HLR cancels the context in the old 3G_SGSN by sending Cancel Location (IMSI). The old 3GJSGSN 
removes the context and acknowledges with Cancel Location Ack. 

• The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_SGSN. The new 3G_SGSN 
acknowledges with Insert Subscriber Data Ack. 

• The HLR acknowledges the Update GPRS Location by sending Update GPRS Location Ack. to the new 
3G_SGSN. 

• The new 3G_SGSN validate the UEs presence in the new RA. If due to regional, national or international 
restrictions the UE is not allowed to attach in the RA or subscription checking fails, then the new 3G_SGSN 
rejects the Routing Area Update Request with an appropriate cause. If all checks are successful, then the new 
3G_SGSN responds to the UE with Routing Area Update Accept (new P-TMSI, new RAI, etc.). 

• The UE acknowledges the new P-TMSI with Routing Area Update Complete. 

• When the location registration procedure is finished, the 3G_SGSN may release the signalling connection 
towards the SRNS for the concerned UE. The SRNS will then release the RRC connection if there is no 
signalling connection between 3G_MSC/VLR and SRNS for the UE. 

4.3.14.1.3 Periodic Registration towards both CN nodes without use of Gs 

This example shows Periodic Registration to both the 3G_MSC/VLR and the 3G-SGSN (i.e. no change of registration 
areas) when the UE is in MM idle state and registered in both the 3GJSGSN and die 3G_MSC/VLR. 

The illustrated transfer of MM signalling to/frpm the UE uses an established RRC connection. This RRC connection 
will be established, is in this case, only for the two registration procedures towards the 3G_SGSN and 3G_MSC/VLR. 

For each indicated MM message sent to/from UE, the CN discriminator indicates either 3G_ SGSN or 3G_MSC/VLR. 
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Figure 4-20: Periodic update procedure when the MS is attached for both CS and PS services 

An RRC connection is established for the periodic registration. Note that this procedure is invoked only when the UE is 
in MM-idle state. The UE sends a Routing Area Update to the UMSC. The UMSC authenticates the P-TMSI signature. 
If the update is successful it sends a Routing Area Accept message. The RRC connection is then released. 

4.3.14.1.5 UE initiated Combined Detach Procedure when using Gs/UMSC 

The UE -Initiated Detach procedure when initiated by the UE is illustrated in Figure 4-21. Each step is explained in the 
following list. 
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3. Detach Accept 
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2. Delete PDP Context Request 



2. Delete PDP Context Response 



Figure 4-21: UE-lnitiated Combined Detach Procedure (The procedure for combined detach when 

using Gs is as defined in GSM 03.60) 

• 1) The UE detaches by sending Detach Request (Detach Type, Switch Off) to the UMSC. Detach Type indicates 
which type of detach that is to be performed, i.e., PS Detach only, CS Detach only or combined Detach. Switch 
Off indicates whether the detach is due to a switch off situation or not. 

• If PS detach, any active PDP contexts in the GGSNs regarding this particular UE may be deactivated. Thicis 
EES 



• If Switch Off indicates that the detach is not due to a switch off situation, the UMSC sends a Detach Accept to 
the UE. 
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Figure 4-31 The states written in italics correspond to those defined in GSM with GPRS. 

4.3.14.3.1 PS -idle state 

The RA update procedure is utilised to update the whereabouts of the UE into SGSN. The updating into SGSN takes 
place irrespectively of the CS MM state in MSC. 



4.3.14.3.2 PS -connected state 

The URA and cell updating and handover procedures presented in Figure 4-31 are based on UMTS YY.03 [2]. In brief, 
the aim in [2] is to introduce functionality that caters for the same functionality as standby/ready in GPRS. The RRC 
shall be designed in such a fashion, which allows the state of the RRC connection to define the level of activity 
associated to a packet data connection. The key parameters of each state are the required activity and resources within 
the state and the required signalling prior to the packet transmission. The operator configurable 
RRC_connection_release timer can be used to release RRC connections in case of very low level of activity and in case 
the QoS requirements e.g. delay requirement allow the release of the RRC connection. 

The cell update and URA update between UE and RNC are used when the UE is in RRC common channel state, i.e., 
when the above mentioned parameters allow to scale down the resources reserved for the UE (for a more detailed 
description on this, see [2]). For example, the purpose of the cell update procedure is to allow the UE to inform its 
current location in the corresponding RRC state. According to [2] the cell update procedure replaces handover in the 
corresponding RRC substate. 

A significant deviation from GPRS is the introduction of the handover procedures for connections supporting traffic 
into IP domain (in RRC cell connected state, see [2]). 

The UE moves to PS-IDLE state in case of expiry of RRC_connection_release timer or an RRC connection failure. 



4. 3. 14. 4 I ssu e s for furthor study 

List of issue s that are for further stud)' related to this chapter and is the following : 

More details arc required with regards to the differences with regards to the "IP - domain" MM compared to GPRS MM , 
especially considering roaming and handover to/from UMTS to GSM/GPRS . 

More d e tails should be provided with regards to the logical relations between UE - CN and UTRAN . CN, and how thes e 
relate to the physical interconnection between UTRAN and the CN nodes(e). namely whether one logical/physical Iu 
can be used to interconnect the UTOAN with the CM . 
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and/or SGSM to the HLR. 



4.3.15 Combined update towards the HLR for a combined 3G- 
(MSC/VLR+SGSN) configuration 

Note: Combined location update procedures are not a high priority architectural requirement for UMTS R99. 

4.3.15.1 Motivation 

In order to optimise the signalling load within the network, reduce operating and maintenance costs and creating the 
possibility to combine cs and ps handover it is essential to open the door in the specifications for combined 3G- 
(MSC/VLR+SGSN) solutions. 

4.3.15.2 Technical description 

For the area concept discussed for the time being, four different cases have to be distinguished: 

- change of UTRAN Registration Area (URA) within the same Routing Area (RA) 

- change of URA and RA within the same Location Area (LA) 

- change of URA, RA, or LA within the same node 

- change of URA, RA, or LA, and node 

For a combined 3G-(MSC/VLR+SGSN) node only in case 4 the UE's HLR has to be updated. If the UE is idle mode for 
the packet and circuit switched traffic a combined 3G-(MSC/VLR+SGSN) node will run the location update procedure 
jointly for the UE's CS and PS domain resulting in one combined location update message, see Figure 4-32. 



HLR 




Node B 



UE 



Figure 4-32 Combined MM Instance For a Combined 3G-(MSC/VLR+SGSN) Node 



Split nodes may have to run one specific location update procedure for any of the two domains resulting in two separate 
location update messages, see Figure 4-33. ^ 



a) Networks which provide the functionality of CS Service Domain and PS Service Domain. 

b) Networks which only provide the functionality of the CS Service Domain. 

c) Networks which only provide the functionality of the PS Service Domain. 
The following terminal configurations shall be allowed: 

a) Terminals which are able to access both to the CS Domain and PS Domain. 

b) Terminals which are only able to access to the PS Domain. 

c) Terminals which are only able to access to the CS Domain. 

It shall be noted that e.g. terminal which is only able to access to the PS Domain supports only mobility management, 
protocols etc. of that particular domain. Hie different configurations given above shall not prevent CS-type services 
from being delivered over the PS domain. 

5 UMTS to UMTS handover for circuit switched 
services 

For UMTS to UMTS Inter-MSC Handover the GSM E i/f transporting BSS AP messages with necessary modifications 
for GSM to UMTS Handover shall be used. 

[Ed note: signaling flows are to be provided and be in line with "GSM to UMTS handover for circuit switched 
services"] 

6 Interoperability between GSM and UMTS 

The requirements for GSM - UMTS interoperability is defined in 22.129 . 
-g- Transparency [from a users perspective] of roaming and handov er 
-5Re-use of existing subscription profiles 
Note; This list is not exhaustive and is FFS. 

This allows easier management and deployment of a new UMTS network . 

UMTS is a system supporting handovers between GSM and UMTS in both directions. To support these handovers 
effectively, the following is required from a dual mode MS/UE supporting simultaneous ISDN/PSTN and packet service 
in GSM/UMTS: 

Depending upon the solution adopted for GSM-UMTS handover, the MS/UE supporting simultaneous ISDN/PSTN and 
packet service may be required to perform appropriate update into CN depending on Hie activity of the UE once the 
handover between GSM and UMTS is completed. This update is needed to avoid any severe interruptions on the 
accessibility of packet services after the handover. 

The nature of the update to be made after the handover in both direction, i.e., from GSM to UMTS and from UMTS to 
GSM, from MS/UE depends on the activity of the UE in the following way: 

ISDN/PSTN connection: RA update only (if RA is changed) 

Packet connection: LA and RA update (if RA and LA are changed) 

Both ISDN/PSTN and packet connection: RA update only (if RA is changed) 

If the RA. LA or both LA and RA are not changed the MS/UE behaviour is for further study 
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4.8 



Location of the IP compression function in UMTS 



4.8.1 



Functional role of SNDCP / PDCP4=3C£ 



Out of the functions devoted to SNDCP in 2G network, only header compression and XID negotiation functions need to 
be considered in UMTS. Hence the tenn-L3£E Packet Data Convergence Protocol (PDCP) is introduced. 



RNC position for header compression is the best place because: 

differential header compression algorithms work better if they are located in the place where packets are more likely to 
be discarded (after having discarded packets the compression algorithm can send a packet with full header 1 ). This place 
is the RNC (where the queues for downstream packets waiting for radio resources are located). 

The compression entity is as close as possible to the reliable link (as in 2G) which in this case is the RLC. Therefore it 
can be stated that a faster recovery of packets is possible after loss of packets in the radio interface and this solution will 
therefore minimize the amount of buffering in the UE and network. 

the compression can be optimized for the used RAN. 

It increases the possible data rates that can be achieved: Locating the compression function in the RAN defers the SGSN 
from the task of opening and processing packets 

efficient inter-system hand-over can be supported 



Figur e 4 - 1 3 bi 6 : Compr ess ion Ent i ty Functionality for UMTS 



4.8.2 



Position for header compression 
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6.1 Circuit Switched Handover and Roaming Principles 



Introduction of a UMTS Core Network necessitates the inter-connection with legacy systems to allow inter-PLMN 
roaming and handover. 

For ease of convergence with the existing networks and the introduction of dual mode handsets, roaming andhandover 
to/from UMTS should be performed in the simplest manner that requires as little change as possible to the legacy 
networks and standards, i.e. inter-MSC handover functionality. 

These principles provide - from a user perspective - transparency ofhandover and roaming. In addition, operators 
providing UMTS services should also allow access to legacy networks using existing subscriber profiles and network 
interfaces. 

Illustrated in Figure 6-1 shows the introduction of a UMTS Core Network for UMTS phase 1 network configuration. 
Notice that it leaves the current GSM specifications mainly untouched whereupon the UMTS core network acts towards 
the GSM MSC like a GSM MSC by providing for example MAF7E for handover purposes. Further, it should be 
observed that GSM subscriptions belong to the HLR whilst UMTS subscriptions exist in the HLR release 99.. 
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Figure 6-1 Inter-Operability between GSM and UMTS 



Note: No physical implementation should be taken from the figure. As a further note, nointerworking functions are 
shown to ease clarity, but however should not be precluded. 

From Figure 6-1 it can be seen that the information exchanged over thelu must provide the necessary parameters to 
enable the core networks to communicate via for example the MAP interface for handover purposes. 

Also note that from the above diagram, existing interfaces are used towards the HLR to allow for subscription 
management based on today's principles using the already defined user profile, providing seamless roaming between the 
2nd generation system and UMTS. 

The existing GSM handover procedures should be re-used to minimise the effects on existing GSM equipment. 



• The anchor concept in GSM for inter-MSC handover should be used for inter-svstem handover between UMTS and 
GSM. 



3GPP 



• The signalling over the A-interface and over the M AP/E-interface should be the same as in GSM 
phase 2+ with possibly addition of some new or updated information elements in some messages. 

• For the set up of the handover leg (user plane) standard ISUP/POTS should be used in line with the principles used 
in GSM. 

• The control signalling over the lu-interface at handover between UMTS and GSM should be based on the A- 
interface signalling at inter-MSC handover in GSM. 

• The signalling over the lu-interface at call set up to/from a dual mode UMTS/GSM mobile station, shall include 
GSM information elements needed for handover from UMTS to GSM. 

In the corresponding way the signalling over the A-interface at call set up to/from a dual mode UMTS/GSM mobile 
shall include UMTS elements needed for handover from GSM to UMTS. 
The data are needed to initiate the handover towards the new BSS/RNC. 

• A target cell based on CGI is sent to the MSC from UTRAN at handover from UMTS to GSM. The CGI points out 
die target MSC and target BSC 

• A target cell based on CGI is sent to the MSC from the BSS at handover from GSM to UMTS. The CGI points out 
the target UMTS MSC and target RNC (UMTS MSC does the translation from CGI to RNC identity). 

6.1.1 UMTS to GSM handover for circuit switched services 

UMTS to GSM handover for circuit switched services is detailed in 23.009 . 

The signalling sequence in Figure 6 * 2 shows the cage when the UMTS MSC (UMSC) and the GSM MSC are located i n 
separate "physical" nodes. 

If the UMSC and MSC are located within the same "phy s ical" node, no MAP signalling and no ISUP signalling ar e 
needed between UMSC and MSC . 

For release 99 it i s expected that the codec is placed in the anchor or non - anchor UMSC (for the UE in UMTS mode) , 
which will have no impact on the signalling. 
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F i gur e 6 - 2. UMTS to GSM handov e r for circu i t sw i tch e d se rvic e s e. g , voic e 

1) SRNS initiates the preparation of UMTS to GSM Handover by sending the P.ANAP message Relocation 

Required to UMSC, This message includes parameters such as Target cell identification and Serving cel l 
id e ntification,, both in the form of CGI according to GSM. 

2) UMSC requests MSC to prepar e for UMTS to GSM Handover, by sending the MAP message PREPARE 

HANDOVER request, The message contains a BSSMAP message Handover Request^ to be cent from MSC t o 
BSS. It includ e s data such as Target and Serving CGI received from the Relocation Required message, an d 
data stored in UMSC indicating type of radio resources required . 

3) MSC sends the BSSMAP message Handover Request to BSS which then allocates necessary radio resources i n 

BSS. 

■ 1)When BSS has allocated necessary radio re s ources it sends the BSSMAP message Handover Reque st 
Acknowledge. This message contains all radio - related information that the UE needs for handover, ie, a 
complete GSM Handover Command m e ssag e to be sent transparently via MSC, UMSC and SRNS to UE . 

including a complete GSM Handover Command message . 
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6) UMSC sends the ISUP message IAM to MSG to establish a circuit ISUP connection between UMSC and MSC . 

7) As acknowledgement to IAM, MSC sends the ISUP message ACM back to UMSC . 

8) UMSC sends the RANAP message Relocation Command to SRNS, including a complete GSM Handov er 

Command message to be sent to UE. 

9) SP.NS sends the RRC message Handover Command to UE. including a complete GSM handover Comman d 

message, to order the UE to start the execution of handover . 

10) Upon detection of UE in BSS> (by reception of the Layerl GSM message Handover A c cess from the UE ), 
which indicates that the correct UE has successful accessed the radio re s ource in the target GSM cell, th e 
BSSMAP message Handover Detect is sent from BSS to MSC. MSC ma}' use this condition to switch th e 
connection to the BSS. 

1 1) MSC sends the MAP message PPiQCESS - ACCESS - SIGNALLING request to UMSC, including th e 
BSSMAP mes s age Handover Detect. UMSC may use this message as trigger point for switch of th e 
connection to the MSC. 

12) To complete the ISUP signalling the ISUP mes s age ANM is sent from MSC to UMSC . 

13) Aft e r Layer 1 and 2 connections are succe s sful^ established; the UE sends the GSM message Handov er 
Complete to BSS. 

1 1) After completed handover, BSS s end s the BSSMAP message Handover Complete to MSC . 

15) MSC sends the MAP message SEND - END . SIGNAL request to UMSC including the BSSMAP messag e 
Handover Complete; 

16) UMSC initiates release of resources allocated by the former SP.NS . 
■13)1) SRNS acknowledges relea s e of resource s. 

6.1 .2 GSM to UMTS handover for circuit switched services 

UMTS to GSM handover for circuit switched services is detailed in 23.009 .Tlie signalling sequence in figure 6 . 3 show s 
the case when the UMTS MSC (UMSC) and the GSM MSC are located in separate "physical" node s. 

If the UMSC and MSC are located within the same "physical" node, no MAP signalling and no ISUP signalling ar e 
needed between UMSC and MSC . 

For relea s e flfl it is expected that the codec is placed in the anchor or non ^ anchor UMSC (for the UE in UMTS mode ), 
which will have no impact on the signalling. 
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F i gur e 6- 3 , GSM to UMTS handov e r for c i rcu i t gw i tch e d se rvic e s o . g , vo i ce 

1 .BSS initiates the preparation of GSM to UMTS Handover^ by sending the BSSMAP message Handover Required t o 
MSC, This message include s parameters such as Target cell identification as CGI> and information to be sent furthe r 
transparent to Target RNC via MSC and UMSC , 

2. MSC requests UMSC to prepare for GSM to UMTS Handover, by s ending the MAP message PREPARE 
HANDOVER* Reque s t This message includes parameters such as Target cell identification and Serving cel l 
identification^ both in the form of CGI, and information to be sent transparent to the Target R.NC via UMSC . 

3iUMSC requests Target P.NC to prepare for GSM to UMTS Handover, by sending the RANAP message Relocatio n 
Request, UMSC translates the Target cell identification (CGI) received in the MAP meccagc PREPARE 
H ANDO VEFi Request, to a FJflC pointer to addr e ss the Target FJJC. This message includes parameters such a s 
bearer related information^ and information received in the MAP message Prepare Handover Request to be sen t 
transparent to the Target P.NC , 

I. When Target RNC has allocated necessary radio resources it sends the RANAP message Relocation Reque st 

Acknowledge to UMSC. This message contains all radio - related information that the UE needs for handover i.e. a 
compl e te RRC message to be sent transparently via UMSC, MSC and BSS to the UE , 

5; UMSC send s the MAP message PREPARE HANDOVER Response to MSC including a complet e 



P.RC message; to be gent trangparent to UE via MSC and BSS . 

6 , MSC sends the ISUP message IAM to UMSC to establish a circuit ISUP connection between MSC and UMS C 

7, As acknowledgement to IAM» UMSC sends the ISUP message ACM back to MSC . 

8 , MSC sends the BSSMAP message Handover Command to BSS,. including a complete RRC message to be s e n t 

transparent to UE via BSS. 

0 CP nHr ih* H<SA/f mPrrnrrP Hnnrfnvpr PnmmnnH in TTP fnrliirimfr n rnmp1ntr> PPT ™ ?r r ^ \* ^rd°r th? UE tO CtOT t 

execution of handover, 

in TTpnn /Wrtinn nf th^ TTF in TnrrrPt PUP TnrrrPt P ATP rtnrtr nrtinjr nr gPMP fnr thr* T TP ^ fa* p A N A p m c CC3g C 

PiClocation Detect is sent from P.NC to UMSC . 

1 1 At mrrptinn nfthft T? AMAP mPfcwffplnntinn TVfprt^ thMTM^r rmHr t1ir> IS/TAP n 1P cr ? ^ PP QCFSS ACCES S 

STHUAT T TMP PpqnPft tn IS/f^P A^P mny nrr> thic mpccinp trijrnw pnint fnr c^n^h th* ™7nn??tion tO til C 

UMSC, ' 

12. To complete the ISUP signalling the ISUP message ANM is sent from UMSC to MSC . 

13, After completed handover^ UE send s the PJ?*C message Handover Complete to Target P t NC . 
H Target F*NC sends the RANAP mes s age P^elocation Complete to UMSC . 

1 5 T TM^P fnnrnHc flip PAMAP mpccngf* P fWntmn PnmplrtP in thn UAP m^c-cogi* ^PATH pfjp STOMAL P.equeCt t O 

16.MSC initiates release of resources allocated by BSS . 
BSS acknowledges release of resources . 

6.2 Packet Switched Handover and Roaming Principles 

The introduction of a UMTS core Network illustrates the requirement for inter-connection with the legacy GSM system 
to allow inter-PLMN roaming and handover. 

Even though there is no current GPRS deployment, the operator may decide to deploy a GPRS network prior to the 
deployment of a UMTS network. Therefore, the introduction of a UMTS Core Network may require to be inter- 
connected to the legacy packet network. 

As in the circuit switched case, roaming andhandover to/from UMTS should be performed in the simplest manner that 
requires as little change as possible to the GPRS network and standards, i.e. inter-GSNhandover functionality. In 
addition, access is provided to the GPRS network using the existing subscriber profiles and current network interfaces. 

A similar figure to Figure 6-1 is illustrated in Figure 6-4. Notice that it also leaves the current GPRS specifications 
mainly untouched whereupon the UMTS core network acts towards the GSN like a GSN by providing for example Gn. 
Further, it should be observed that GPRS subscriptions belong to the HLR whilst UMTS subscriptions exist in the HLR 
release 99. 




Figure 6-4: Inter-Operability between GSNs and UMTS 

Note: No physical implementation should be taken from Figure 6-4. As a further note, nointerworking functions are 
shown to ease clarity, but however should not be precluded. 

From Figure 6-4 it can be seen that to provide inter-working between legacy packet switched and UMTS packet 
switched services, the information exchanged over the Iu must provide the necessary parameters to enable the core 
networks to communicate via for example the Gn interface for handover purposes. 

Also note that from the above diagram, the same principles are used as in the circuit switched services to provide 
seamless roaming. 

6.2.1 Implications 

• The active PDP context resides in the same GGSN even after a handover between GSM and UMTS (both 
directions). This corresponds in principle to the anchor concept on the circuit switched side, but note that 
whereas packet sessions are long lived, the anchor MSC remains only for the duration of a CS call (typically 
much shorter than a packet session). 

• Assuming an internal structure in UMTS CN that contains logical GGSN and SGSN nodes, the signalling over 
the inter-system GGSN-SGSN interface should be a joint evolution of Gn for the GSM system and UMTS. I.e., 
when Gn evolves in the sequence of GSM releases, Gn should include any new or updated information necessary 
for interoperation. 

• The corresponding SGSN-SGSN inter-system interface (also Gn) should also be evolved together. However, in 
this case the changes relative to the current GPRS release may possibly be more profound. 

6.2.2 Signalling procedures 

The signalling procedures shows how handover UMTS <-> GSM GPRS can be done. The parameters carried by each 
message is not complete and shall be seen as examples of important information carried be the messages. 

The signalling sequences shows the case when the UMTS 3G_SGSN and the GPRS 2G_SGSN are located in separate 
"physical" nodes. 

If the 3G_SGSN and 2GSGSN are located within the same "physical" node, no signalling are needed between 
3G_SGSN and 2G_SGSN. 



For handover in the UMTS to GSM GPRS direction the intention is to re-use the handover principles of GSM GPRS 
today in order to limit the changes in GSM GPRS and to take the changes if any on the UMTS side. The below specified 
messages is standard GSM 2+ messages (when applicable) 

6.2.2.1 Handover from UMTS to GSM GPRS 

Handover from UMTS to GSM GPRS is detailed in 23.060. 
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3)The UE sends a Routing Area Update Request (old RAI, old P - TMSI) to th? new 2G_SGSM. The BSS shall ad d 
the Cell Global Identity including the P.AC and LAC of the cell where the me s sage wag received befor e 
passing the message to the 2G_SGSN . 

S)Thenew 2G_SGSN sends SGSN Context Request (old RAL old P - TMSI, New SGSN Address) to the ol d 

3G_SGSN to get tlie MM and PDP contexts for the UE (The old RAI received from the UE is used to deriv e 
th e old 3G_SGSN address). 

I) Qld 3GJ5GSN sends SRNS Context Request to SRNS in order to receive tlie GTP - PDU sequence numbers of th e 

GTP - PDUs to be next sent between UE and GGSN. SRNS r e sponds with SFJsTS CONTEXT RESPONS E 
including tlie GTPJPDU sequence numbers and sequence numbers of last successfully received UL RLC - 

5) The old 3G_SGSN responds with SGSN Context Respons e (MM Context, e.g. IMSL PDP Contexts, e.g. APN) . 

6) Security functions may be executed. 

7) The new 3 G_SGSN sends an SGSN Context Acknowledge message to tlie old 3G_SGSN , This informs tlie ol d 

3G_SGSN that tlie new 2G_SGSN is ready to receive data packets belonging to the activated PDP contexts . 

8) Qld 3GJSGSN sends Iu P^elease Command to SPtNS, In case of lossless handover this message indicates tlie I P 

addres s to be used to return the unsent PL GTP - PDUs , Upon reception of this message tlie SPlNS starts t o 
return GTP - PDUs to old 3G_SGSN, SRNS responds with Iu Release Complete . 

9) The new 2 G_SGSN send s Update PDP Context Request (new SGSN Address) to tlie GGSN concerned, Th e 

GGSN update their PDP context fields and return Update PDP Context Response . 

lCQThe new 3GJSGSN inform s tlie HLR of the change of SGSN by sending Update GPRS Location (SGSN 
Number, SGSN Address, IMSI) to the HLR. 

1 l)The HLR sends Cancel Location (IMS I) to the old 3G_SGSN, Tlie old 3G_SGSN removes tlie MM and PD P 
contexts. 

The old 3G_SGSN acknowledges with Cancel Location Ack (IMSI) . 

12) The HLR. s ends In s ert Sub s criber Data (IMSL GPRS subscription data) to the new 2GJ5GSN, Tlie 2G_SGSN 

rnnctmptc in rrmfpvt fnrthp T TP nnA fPtnrnc in Tncnrt gnhc/M-iW A nV (TA/f^f) mffgjge tC the HLP„ 

13) The HLP. acknowledges tlie Update Location by sending Update GPR.S Location Ack (IMSI) to tlie new 

3G_SGSN, 

I I) Th e new 2G_SGSN validates the UE's pr e sence in the new RA, The new 2G_SGSN constructs MM and PD P 

contexts for the UE, A logical link is established between tlie new 3G_SGSN and the UE, To avoid dat a 
duplication tlie sequence numbers of the PJX link that was used before tlie handover may be used t o 
initialise the logical link. Tlie new 2G_SGSN responds to the UE with Routeing Area Update Accep t 
(P-TMSI). 

15)The UE acknowledges tlie new P - TMSI with a Routing Area Update Complete (P - TMSI) . 



6.2.2.2 Handover from GSM GPRS to UMTS 

Handover from GSM GPRS to UMTS is detailed in 23.060. 
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F i gur e 6- 6 ; G SM G PRS to UMTS , I nt e r S G SN Rout i ng Aroa Updat e Proc e dur e 

1) The UE/network decides to perform handover which leads to that the UE switch to the new cell» details for thi s 

2) The UE sends a Routing Area Update Request (old RAI ; old P - TMSI) to the new 3G_SGSN, The SRN S 

shall add an identifier of the area where the message was received before passing the message to th e 
3G_SGSN 

3) The new 3G_SGSN sends SGSN Content Request (old RAI, old P TMSh New SGSN Address) to the ol d 

2G_SGSN to get the MM and PDP contents for the UE (The old RAI received from the UE is used to d e riv e 
the old 2G_SGSN address). The old 2G_SGSN responds with SGSN Context Response (MM Context e.g . 
IMSIj PDP Contexts; e,g, APN) . 

1)Securit} f functions may be executed. 



I A. 



ciiui: imu icai ui ipc^iucu siyte til UUCUflieilL. 



5) The new 3G_SGSN request the SRNS to establieh of a rndio access bearer by sending ff A Ft frccignmcn t 

Request to the SFJflS. The SRNS responds with RAB Assignment Respons e. 

6) The new 3G_SGSN sends an SGSN Context Acknowledge message to tlie old 2G_SGSN, This informs the o ld 

2G_SGSN that the new 3GJSGSN is ready to receive data packets belonging to the activated PDP cont e xts . 

7) The new 3G_SGSN sends Update PDP Context Request (new SGSN Address) to the GGSN concerned, Th e 

GGSN update their PDP context fields and return Update PDP Context Response . 

S)Th e new 3G_SGSN informs the HLR of the change of SGSN by sending Update GPRS T ocntion (SGSN 
Number, SGSN Address, IMSI) to the HLR. 

9) The HLR sends Cancel Location (MSI) to the old 2G_SGSN t The old 2GJSGSN removes the MM and PD P 

contexts . 

The old 2G_SGSN acknowledges with Cancel Location Ack (IMSI) . 

10) The HLR sends Insert Subscriber Data (IMSL GPRS subscription data) to the new 3GJ5GSN, The 3G_SGSN 
construct s an MM context for the UE and returns an Insert Subscriber Data Ack (IMSI) message to the HLR .. 

1 l)The HLPi acknowledges the Update GPFiS Location by sending Update Location Ack (IMSI) to the new 
3G_SGSN, 

12) The new 3G_SGSN validate s the UE's presence in the new P. A, The new 3GJSGSN constructs MM and PD P 
contexts for the UE, A logical link is established between the new SGSN and the UE, The new 3G_SGSN 
responds to the UE with x^Routing Area Update Accept (P - TMSI) . 

13) The UE acknowledges the new P-TMSI with a x_PtOuting Area Update Complete (P - TMSI) . 

Note 1 ; The functionality for forward of packet s and handling of GTP s equence numbers (within the box) is a subjec t 
fore more investigation, i.e, FFS. The GPPtS principles should apply . 



Annex A (Informative)Reduction of UMTS signalling 

A. 1.1 GLR Concept 

The benefit of the Gateway Location Register (GLR) is the reduction in signalling traffic between networks. GLR is an 
optional network element which shall not affect the MAP protocol. 

A. 1 . 1 . 1 Overview of the GLR Concept 

The GLR is a node between the VLR and the HLR, which may be used to optimise the handling of subscriber location 
data across network boundaries. 

In Figure 1, the GLR interacts with HLRa and VLRb for roamers on Network B. The GLR is part of the roaming 
subscriber's Home Environment. When a subscriber to HLRa is roaming on Network B the GLR plays the role of an 
HLR towards VLRb and the role of a VLR towards HLRa. The GLR handles any location change between different 
VLR sendee areas in the visited network without involving HLRa. 
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In RRC Idle mode it is the broadcasted MM system information (e.g. information about the present Location Area and 
present Routing Area) that determines when the UE initiates a location registration procedure towards the CN. An UE in 
state CS-IDLE will in RRC Idle mode, initiate Location Area update towards the CN when crossing LA border. An UE 
in state PS-IDLE will in RRC Idle mode initiate Routing Area update towards the CN when crossing RA border. 

In RRC Connected mode, the UE receives the MM system information on the established RRC connection. (I.e. the 
broadcasted MM system information is not used by the UE in the RRC connected mode.) An UE in state CS-IDLE will, 
in RRC Connected mode, initiate Location Area update towards the CN when receiving information indicating a new 
Location Area. An UE in state PS-IDLE will, in RRC Connected mode, initiate Routing Area update towards the CN 
when receiving information indicating a new Routing Area. An UE in state CS-CONNECTED will, in RRC Connected 
mode, not initiate Location Area update towards the CN. An UE in state PS- CONNECTED will, in RRC Connected 
mode, not initiate Routing Area update towards the CN. 

In CS-DET ACHED mode the UE will not initiate any Location Area update and this independent of the RRC mode. In 
PS-DETACHED mode the UE will not initiate any Routing Area update and this independent of the RRC mode. 

In additional to normal location registration when changing registration area, the UE may (network options) perform CS 
periodic registration when in CS-IDLE state and PS periodic registration when in PS-IDLE state. The respective 
periodic registration may be on/off on Location Area respective Routing Area level. 

On the Mobility Management level, IMSI and CS related TMSI are used as UE identities in the CS service domain, and 
IMSI and PS related TMSI are used as UE identities in the PS service domain. The IMSI is the common UE identity for 
the two CN service domains. 

A signalling connection between the UE and the CN refers to a logical connection consisting of an RRC connection 
between UE and UTRAN and an Iu signalling connection ( i; one RANAP instance") between the UTRAN and the CN 
node. The CS service domain related signalling and PS service domain related signalling uses one common RRC 
connection and two Iu signalling connections ("two RANAP instances"), i.e. one Iu signalling connection for the CS 
.service domain and one Iu signalling connection for the PS service domain. 

4.3.1 .1 Use of combined procedures for UMTS 

The use of separated PS and CS mobility mechanisms within the UE and within the CN may lead to non-optimal usage 
of the radio resource (for example a UE in PS idle and CS idle state would perform both location updates (for the CS 
mechanism) and Routing area updates (for PS mechanisms)). 

UMTS should optimise the use of radio resources., The use of combined updates (similar to the current GSM/GPRS Gs 
combined update mechanism) may enable this. To offer flexibility in the provision of mobility management for UMTS, 
it should be possible to use combined mechanisms for location management purposes as well as for attach/detach status 
purposes. 

From the UE perspective it should be possible for the UE to perform combined update mechanisms (operator option). 
UMTS Phase 1 R99 terminals should support the use of both combined and separate mechanisms. The support of this 
feature by all UMTS mobiles will also ease evolution of UMTS MM in the future. 

In the UMTS specifications the RAN will not co-ordinate mobility management procedures that are logically between 
the core network and the MS. This includes: location management, authentication, temporary identity management and 
equipment identity check. 

The issu e s of s ecurity,, temporary identifiers^ CS and PS periodic registrations and PS DETACHED/CS DETACHED 
need to be studied. 
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4.3.2 Description of the Location Management and Mobility Management 
Concept 

4.3.2.1 Area concepts 

For the mobility functionality four different area concepts are used. Location Area and Routing Area in the CN as well 
as UTRAN Registration Area and Cell areas in the UTRAN. 
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Figure 4-10: Relationship between different areas. 

4.3.2.1.5 Hierarchical tracking concept 

A packet UE (in RRC connected mode) is tracked at the cell level by RNC during an active connection. 

A packet UE (in RRC connected mode) is tracked at the URA level by RNC when no data are actively transfer, and the 
probability of data transfer is quite high. 

A packet UE (in PS-Idle state) is tracked at the Routing Area level by SGSN when no data is actively transfered and the 
probability of data transfer is quite low.The network operator should be able to optimise paging and updating load by 
controling the size of the different areas and the probability of data transfer (controlled by the RRC_connection_release 
timer). For example, one operator may decide that URA are small and that RRC connection are released after a 
relatively short time of inactivity, so that most attached packet UE are tracked in the Routing Area level (optimum for 
packet UE mainly using client-server type of service). 

Another operator may decide that URA are large, and that RRC connection are released only if RRC connection is lost, 
so that most attached packet UE are tracked at the URA level. 

The procedure for the releasing of the RRC connection can be found in 23.060 under the Iu release procedure. The URA 
update procedures can be found in 25.33 1 . 

Different timer values are required for the URA Update Timer and for the RRC Connection Release Timer It is fo r 
further study whether the duration of the RRC_Connection_Releage timer is get on a per UE basic, or configurable by 
the operator to be the s ame for all UE . 

4.3.3 Relationship between MM and SM states for an UE 

When a UE is attached to PS service, it may have or not some PDP context established. 

If the UE has no PDP context established (SM-Inactive), no radio access bearer are established for PS service. The UE is 
in RRC connected mode, only if the state is UMTS CS-CONNECTED state or UMTS PS-CONNECTED state (i.e. only 
a PS signaling connection is established). 
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If the UE has at least one PDP context established (SM-Active), the UE may be in UMTS PS-CONNECTED state 
UMTS PS-IDLE state. 
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Figure 4-17: Interface information transfer for location update when changing VLR area 

The RRC connection is established, if not already done. The UE sends the initial message Location Area Update 
Request (old TMSI, old LAL etc.) to the new 3G_MSC/VLR. The old TMSI and the old LAI are assigned data in 
UMTS. The SRNS transfers the message to the 3GJV1SC/VLR. The sending of this message to 3G_MSC/VLR 
will also imply establishment of a signalling connection between SRNS and 3G_MSC/VLR for the concerned 

UE. Thr W_M^r/\n P fWrmmPC Hip npw T nrotinn Ar^n frtr ihr> T TP WI^W ^ ^JV/^r Aff p derT/er th e 

new LAI from information supplied by the UE or by the SRNS is ffs. The UTRAN shall add the RAC and th e 
LAC of the cell where the message was received before passing the message to the MSC . 

Hie new 3G_MSC/VLR sends an Send Identification Request (old TMSI) to the old 3GJV1SC/VLR to get the 
IMSI for the UE. (The old LAI received from UE is used to derive the old 3G_MSC/VLR identity /address.) The 
old 3G_MSC/VLR responds with Send Identification Ack. (IMSI and Authentication triplets). 

Security functions may be executed. 

The new 3G_MSC/VLR inform the HLR of the change of 3G_MSC/VLR by sending Update Location (IMSI, 
MSC address, VLR number) to the HLR. 

The HLR cancels the context in the old 3G_MSC/VLR by sending Cancel Location (IMSI). Hie old 
3G_MSC/VLR removes the context and acknowledges with Cancel Location Ack . 

The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_MSC/VLR. The new 
3G_MSC/VLR acknowledges with Insert Subscriber Data Ack. 
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• The HLR acknowledges the Update Location by sending Update Location Ack. to the new 3G_MSC/VLR. 
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•__The RRC connection is established, if not already done. The UE sends the initial message Routing Area Update | 
Request (old P-TMSI, old RAI, etc.) to the new 3G_SGSN. The old P-TMSI and the old RAI are assigned data in 
UMTS. The SRNS transfers the message to the 3G_SGSN. The sending of this message to 3G_SGSN will also 
imply establishment of a signalling connection between SRNS and 3GJSGSN for the concerned UE. The 
UTRAN shall add the RAC and the LAC of the cell where the message was received before passing the messag e 
to the SGSN. 

. The 3G SGSN determine s the new F.outinfl Area for the UE. Whether ths 3G SGSN derive th» n^v P M fr o m 
information supplied by the UE or by the SFJMS is -ffc . 

• The new 3GJSGSN send an SGSN Context Request (old P-TMSI, old RAI) to the old 3G_SGSN to get the IMSI 
for the UE. (The old RAI received from UE is used to derive the old 3G_SGSN identity/address.) The old 
3G_SGSN responds with SGSN Context Response (e.g. IMSI, PDP context information and Authentication 
triplets). 

• Security functions may be executed. 

• The new 3G_SGSN informs the HLR of the change of 3G_SGSN by sending Update GPRS Location (IMSI, 
SGSN number, SGSN address) to the HLR. 

• The HLR cancels the context in the old 3G_SGSN by sending Cancel Location (IMSI). The old 3G_SGSN 
removes the context and acknowledges with Cancel Location Ack. 

• The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3GJSGSN. The new 3G_SGSN 
acknowledges with Insert Subscriber Data Ack. 

• The HLR acknowledges the Update GPRS Location by sending Update GPRS Location Ack. to the new 
3G_SGSN. 

• The new 3G_SGSN validate the UEs presence in the new RA. If due to regional, national or international 
restrictions the UE is not allowed to attach in the RA or subscription checking fails, then the new 3G_SGSN 
rejects the Routing Area Update Request with an appropriate cause. If all checks are successful, then the new 
3GSGSN responds to the UE with Routing Area Update Accept (new P-TMSI, new RAI, etc.). 

• The UE acknowledges the new P-TMSI with Routing Area Update Complete. 

• When the location registration procedure is finished, the 3G_SGSN may release the signalling connection 
towards the SRNS for the concerned UE. The SRNS will then release the RRC connection if there is no 
signalling connection between 3G_MSC/VLR and SRNS for the UE. 

4.3.14.1.3 Periodic Registration towards both CN nodes without use of Gs 

This example shows Periodic Registration to both the 3G_MSC/VLR and the 3G-SGSN (i.e. no change of registration 
areas) when the UE is in MM idle state and registered in both the 3G_SGSN and the 3G_MSC/VLR. 

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection 
will be established, is in this case, only for the two registration procedures towards the 3GJSGSN and 3G_MSC/VLR. 

For each indicated MM message sent to/from UE, the CN discriminator indicates either 3G_ SGSN or 3G_MSC/VLR. 
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Figure 4-20: Periodic update procedure when the MS is attached for both CS and PS services 

An RRC connection is established for the periodic registration. Note that this procedure is invoked only when the UE is 
in MM-idle state. The UE sends a Routing Area Update to the UMSC. The UMSC authenticates the P-TMSI signature. 
If the update is successful it sends a Routing Area Accept message. The RRC connection is then released. 

4.3.14.1.5 UE initiated Combined Detach Procedure when using Gs/UMSC 

The UE-Initiated Detach procedure when initiated by the UE is illustrated in Figure 4-21. Each step is explained in the 
following list. 
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Figure 4-21: UE-Initiated Combined Detach Procedure (The procedure for combined detach when 

using Gs is as defined in GSM 03.60) 

• 1) The UE detaches by sending Detach Request (Detach Type, Switch Off) to the UMSC. Detach Type indicates 
which type of detach that is to be performed, i.e., PS Detach only, CS Detach only or combined Detach. Switch 
Off indicates whether the detach is due to a switch off situation or not. 

• If PS detach, any active PDP contexts in the GGSNs regarding this particular UE mav be deactivated.. This is 
EES 



If Switch Off indicates that the detach is not due to a switch off situation, the UMSC sends a Detach Accept to 
theUE. 
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Figure 4-31 The states written in italics correspond to those defined in GSM with GPRS. 

4.3.14.3.1 PS -idle state 

The RA update procedure is utilised to update the whereabouts of the UE into SGSN. The updating into SGSN takes 
place irrespectively of the CS MM state in MSC. 



4.3.14.3.2 PS -connected state 

The URA and cell updating and handover procedures presented in Figure 4-3 1 are based on UMTS YY.03 [2], In brief, 
the aim in [2] is to introduce functionality that caters for the same functionality as standby/ready in GPRS. The RRC 
shall be designed in such a fashion, which allows the state of the RRC connection to define the level of activity 
associated to a packet data connection. The key parameters of each state are the required activity and resources within 
the state and the required signalling prior to the packet transmission. The operator configurable 
RRC_connection_release timer can be used to release RRC connections in case of very low level of activity and in case 
the QoS requirements e.g. delay requirement allow the release of the RRC connection. 

The cell update and URA update between UE and RNC are used when the UE is in RRC common channel state, i.e., 
when the above mentioned parameters allow to scale down the resources reserved for the UE (for a more detailed 
description on this, see [2]). For example, the purpose of the cell update procedure is to allow the UE to inform its 
current location in the corresponding RRC state. According to [2] the cell update procedure replaces handover in the 
corresponding RRC substate. 

A significant deviation from GPRS is the introduction of the handover procedures for connections supporting traffic 
into IP domain (in RRC cell connected state, see [2]). 

The UE moves to PS-IDLE state in case of expiry of RRC_connection_release timer or an RRC connection failure. 

4. 3.14. 4 I ssu e s for furth e r study 

List of issues that are for further stud)- related to this chapter and is the following : 

More detail s ar e required with regards to the differences with regards to the "IP - domain" MM compared to GPP.S MM , 
especially considering roaming and handover to/from UMTS to GSM/GPRS . 

Mnrr rirMilr rhnnlfl hpprnviHpH ivith rppnrrlr tn th P Inpirnl rnlntinnc hnU^n TTF.PM nnH T TTP /^T r^j ^ fr mv 
rrhtr tn thpphyrinl intprrnnnprtinn hphvppn TTTP A "NT nnH tlir* C\l nnHpr(r) nnmnly ivti^h ?r legi^Fphycical Iu 

ran be used to interconnect the UTRAN with the CM . 
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4.3.15 Combined update towards the HLR for a combined 3G- 
(MSCA/LR+SGSN) configuration 

Note: Combined location update procedures are not a high priority architectural requirement for UMTS R99. 

4.3.15.1 Motivation 

In order to optimise the signalling load within the network, reduce operating and maintenance costs and creating the 
possibility to combine cs and ps handover it is essential to open the door in the specifications for combined 3G- 
(MSC/VLR+SGSN) solutions. 

4.3.15.2 Technical description 

For the area concept discussed for the time being, four different cases have to be distinguished: 

- change of UTRAN Registration Area (URA) within the same Routing Area (RA) 

- change of URA and RA within the same Location Area (LA) 

- change of URA, RA, or LA within the same node 

- change of URA, RA, or LA, and node 

For a combined 3G-(MSC/VLR+SGSN) node only in case 4 the UE ; s HLR has to be updated. If the UE is idle mode for 
the packet and circuit switched traffic a combined 3G-(MSC/VLR+SGSN) node will run the location update procedure 
jointly for the UE's CS and PS domain resulting in one combined location update message, see Figure 4-32. 
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Figure 4-32 Combined MM Instance For a Combined 3G-(MSC/VLR+SGSN) Node 

Split nodes may have to run one specific location update procedure for any of die two domains resulting in two separate 
location update messages, see Figure 4-33. 
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a) Networks which provide the functionality of CS Service Domain and PS Service Domain. 

b) Networks which only provide the functionality of the CS Service Domain. 

c) Networks which only provide the functionality of the PS Service Domain. 
The following terminal configurations shall be allowed: 

a) Terminals which are able to access both to the CS Domain and PS Domain. 

b) Terminals which are only able to access to the PS Domain. 

c) Terminals which are only able to access to the CS Domain. 

It shall be noted that e.g. terminal which is only able to access to the PS Domain supports only mobility management, 
protocols etc. of that particular domain. The different configurations given above shall not prevent CS-type services 
from being delivered over the PS domain. 

5 UMTS to UMTS handover for circuit switched 
services 

For UMTS to UMTS Inter-MSC Handover the GSM E i/f transporting BSSAP messages with necessary modifications 
for GSM to UMTS Handover shall be used. 

[Ed note: signaling flows are to be provided and be in line with "GSM to UMTS handover for circuit switched 
services"] 

6 Interoperability between GSM and UMTS 

The requirements for GSM - UMTS interoperability is defined in 22. 129 . 
-^ Transparency [from a users perspective] of roaming and handove r 
-S F.e - use of existing subscription profiles 
Note; This list is not exhaustive and i s FFS. 

This allows easier management and deployment of a new UMTS network . 

UMTS is a system supporting handovers between GSM and UMTS in both directions. To support these handovers 
effectively, the following is required from a dual mode MS/UE supporting simultaneous ISDN/PSTN and packet service 
in GSM/UMTS: 

Depending upon the solution adopted for GSM-UMTS handover, the MS/UE supporting simultaneous ISDN/PSTN and 
packet service may be required to perform appropriate update into CN depending on the activity of the UE once the 
handover between GSM and UMTS is completed. This update is needed to avoid any severe interruptions on the 
accessibility of packet services after the handover 

The nature of the update to be made after the handover in both direction, i.e., from GSM to UMTS and from UMTS to 
GSM. from MS/UE depends on the activity of the UE in the following way: 

ISDN/PSTN connection: RA update only (if RA is changed) 

Packet connection: LA and RA update (if RA and LA are changed) 

Both ISDN/PSTN and packet connection: RA update only (if RA is changed) 

rf the P.A, LA or both LA and P.A are not changed the MS/UE behaviour is for further study 
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Tokyo, Japan, March 6 tn - 9 , 2000 



To: 



S1,S1R00 Ad Hoc 



CC: 



CN, CN1 



SOURCE: 3GPP SA2 
TITLE: Definitions for R00 

S2 would like to thank the SI R00 Ad Hoc for its liaison statement on the domain definitions 
contained in SI -IP 000070. S2 has now agreed to a set of definitions for use within the R00 
work program. These can be found in s2-000537 which is attached to this liaison statement. 

S2 has considered S 1 's proposal to modify the definition of the PS domain, however, S2 has 
decided that it needs to define a separate subsystem from the PS domain. This new 
subsystem. IP Multimedia Subsystem, is intended to be independent of the access technology, 
e.g. PS domain. Hence, it is necessary for the architecture work to distinguish between the PS 
domain and the IP Multimedia Subsystem. S2 have defined the PS services set which 
includes the services supported by the IP Multimedia Subsystem and the services supported 
by the PS domain (IP Connectivity Services). S2 invites SI to use the terms PS and CS 
services when classifying their services rather than the domains. 



S2 asks that SI and CN consider these definitions and use them within their own work on 
R00. 
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TSGS2#12 S2-000537 



Agenda Item: 



R00 Definitions 



Source: 



Drafting group 



Title: 



Release 2000 Definitions 



Document for: 



Decission 



R00 Definitions 



For R99 the term Domain was defined as a grouping of physical entities, due to colliding definition in other 
standardisation foras, it is suggested to find another wording. Because of our history the term domain will 
still remain in some definitions. 

The following definitions are proposed to be included in TR 23.821 and eventually to be included in TS 
23.002. 

CS Services: Telecommunication services provided to "POTS" clients via 24.008 CC. 

PS Connectivity Services: EP connectivity service provided to IP clients via 24.008 SM. 

IM Services: Services that require support on the Call Control level carried on top of the PS connectivity 
services (this may include an eqvivalent set of services to the relevant subset of CS Services). 

PS services: The superset of IM services and PS connectivity Services. 

CS CN domain: comprises all core network elements for provision of CS services. 

PS CN domain: comprises all core network elements for provision of PS connectivity services. 

IM CN subsystem: (IP Multimedia CN domain) comprises all CN elements for provision of IM services 

Sevice Subsystem: Comprices all ell ements providing capabilities to support operator specific services (e.g. 
IN and OSA) 

External Applications: Applications on an external IP host. PS connectivity external applications access 
the network via the PS connectivity services. Service Control External Applications access the network via 
the capabilities of the (IM CN Subsystemdomain) 

The User Equipment domain encompasses a variety of equipment types with different levels of 
functionality. These equipment types are referred to as user equipment (terminals), and they may also be 
compatible with one or more existing access (fixed or radio) interfaces e.g. dual mode UMTS-GSM user 
equipment. The user equipment includes a removable smart card (USIM) that may be used in different user 
equipment types. The user equipment is further sub-divided in to the Mobile Equipment (ME) and the User 
Services Identity Module (USIM). The ME performs radio transmission and contains applications. The 
mobile equipment may be further sub-divided into several entities, e.g. the one which performs the radio 
transmission and related functions, Mobile Termination, MT, and the one which contains the end-to-end 
application or (e.g. laptop connected to a mobile phone), Terminal Equipment (TE). The USIM contains 
data and procedures that unambiguously and securely identifies it. These functions are typically embedded 



in a stand-alone smart card. This device is associated to a given user, and as such allows identifying this 
user regardless of the ME he uses. 

The Radio Access Network domain consists of the physical entities, which manage the resources of the 
radio access network, and provides the user with a mechanism to, access the core network. The Access 
Network Domain comprises roughly the functions specific to the access technology. 
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